Source Generators

[marss72]

Since LanguageExt provides types like Result or Error, why not use them, and add some source generators, that would modify each method under the following conditions:

1. Method returns the Error type (or Result...)
2. Method has an attribute, like SurroundTryAttribute.

That would cause the method to be transformed in the compile time into a try{existing code}-catch block, and when an exception would be thrown, it wouldn't throw the exception, it would return it instead in the Error type.

I know I can use the Prelude.Try(), but is there an actual built-in way to convert it into the Error and Result type, or do I need to do it all myself? Source generators like this may improve the performance of the library, and reduce the code required to accomplish a (repetitive) task.

[louthy]

• re: Result - https://github.com/louthy/language-ext/wiki/Frequently-Asked-Questions#where-is-result
• re: the idea - source-generators can only append new code (if I understand them correctly), you can't modify existing methods/types in-place. So, I don't think it would work.

I'm not overly keen on the idea if I'm totally honest, it's a bit too magic.

Anyway, don't use Result, it isn't meant for public consumption. Use Fin. I think there's a ToFin on Try. You could also use Eff which is more for side-effecting functions.

[marss72]

There is no ToFin on Try. And, how can I use Fin asynchronously (MatchAsync for example)?

[louthy]

FinAsync<A> doesn't exist, EitherAsync<Error, A> does though.

Not sure how deep into language-ext you are, but if you're just starting out, it's worth moving to v5-beta.

Some reading:

• Proposal: Drop all Async variants
• Where is OptionAsync, EitherAsync, and TryAsync?
• Higher Kinds in C# series on my blog - introducing the new concepts in v5.

The new IO<A> monad is probably the Try<A> that you always wanted!

[marss72]

I'm new to LanguageExt. I know some basics, but not more advanced concepts yet.

Could you please explain the IO<A>, and if it's suitable even if the method does not do any IO operations?

[louthy]

There's a good introduction to this in the Monads article on my blog. Before creating the IO monad from scratch.

'IO' obviously has a meaning in computer hardware and I'd be hard-pressed to argue with that. But, really what the IO<A> monad is, is a way to get effects that are different every time you call them (like DateTime.Now) and make them pure.

it should be possible to replace a pure expression with the value it evaluates to with no change in behaviour. Clearly, something like DateTime.Now doesn't fit that bill. If I replace DateTime.Now with the current date-and-time then it will be frozen forever.

If, instead, I didn't use DateTime.Now, I used () => DateTime.Now. A Func<DateTime> value. Then the purity guarantees hold.

So, IO<A> is all about making things that have side-effects, pure. The one thing that IO<A> doesn't do: it doesn't catch exceptions. So, there's Eff<A>, which does all of what IO<A> does, but with additional exception catching. However, there are primitives to help you deal with errors: .Catch and @catch, Choice and | with the IO<A> monad. These can stop exceptions propagating. The place where any unhandled exceptions manifest is at the .Run() method.

One thing it's also worth saying. There's nothing wrong with doing something like this:

Option<int> Divide(int x, int y)
{
    try
    {
        return Some(x / y);
    }
    catch(DivideByZeroException)
    {
        return None;
    }
}

All we're doing in that example is dealing with the fact that in C#-land people have liberally used exceptions for non-exceptional failures forever. So, it's a case of picking and choosing your battles. The Divide function above is referentially-transparent. It doesn't matter if, within, we've had to catch an limitation in the language (or a library), as long as the pure contract is honoured.

The result depends entirely on the arguments passed. No external resource or state has been mutated. And we didn't depend on any external state.