Replacement for Result<T>

[rhemsuda]

Hey there. Awesome library.

I got started with 3.4.0 and realized I was super far behind, but I've already used Result quite extensively. I noticed that it's missing in 5.0.0? Is there meant to be a replacement for it? Apologies if I'm just ignorant and can't find it.

Cheers!
Kyle

[louthy]

https://github.com/louthy/language-ext/wiki/Frequently-Asked-Questions#where-is-result

[rhemsuda]

Thank you so much! Is there somewhere I can chat with you or other devs who use this library? The wiki for Aff/Eff seems to either be outdated or I'm using the wrong version of the library.

[louthy]

The wiki for Aff/Eff seems to either be outdated or I'm using the wrong version of the library.

The in-progress v5 beta is a major refactor from v4 (once in a decade refresh of the library), so the documentation is still in-flux because of this, but I am working through it as the API settles down. The short of it is Aff is now is not needed as Eff can do asynchronous and synchronous computations.

My blog series is the best introduction to the new functionality right now. I have also started an FAQ recently to try and capture some of the questions that will come up as part of this big refactor.

The following samples from the Samples folder are v5 leveraging samples and are therefore a useful guide:

• EffectsExamples is entirely built using the Eff monad and covers quite a lot of functionality in its examples.
• Newsletter is a real-world application that I use to send my blog's newsletter to the subscribers. It takes the idea of trait-based programming to the extreme in that it uses K<M, A> instead of Eff<RT, A>. M is then constrained to be a fallible monad. An RT environment is also threaded through that must have certain traits. That means the code can be run with any monad/RT as long as it supports the traits.
  • I wouldn't necessarily recommend this approach, but it's useful to see how you can generalise an entire application this way. Only when the Send.newsletter function is run do we inject the type of monad (in this case an Eff)
• CardGame uses a lot of what is covered in the Higher-Kinds series on my blog to implement a game of Pontoon/21. It wraps up StateT, OptionT, and IO into a Game monad that runs the game and significantly reduces boilerplate.

The API documentation is also a good place to start. It is generated from the comments in the code, yes, but I have developed a documentation generator that also allows me to add context to the various sections of the project. For example, in the root of LanguageExt.Core you'll see an introduction to the key areas of the library. These context-setting introductions are the documentation that I am working on right now, so are probably more useful overall.

In terms of talking to people, the Discussions tab is your friend. Ask anything you like there and either myself or someone else from the community will reply.

[rhemsuda]

Wicked. Awesome work man. As a Haskeller forced to use C# for work this is going to do wonders. You’re doing gods work! Haha

Thanks,
Kyle

[louthy]

As a Haskeller forced to use C# for work this is going to do wonders.

Ah, you should have said, I'd have worded this quite differently! I should probably have an 'Intro for Haskellers' article. I'll have a think about that. But, instead of me having to introduce the pure-FP concepts it would be more "this is how 'that thing you're used to' works in C#".

We can do most of the good Haskell stuff now (abstraction over 'higher-kinded' traits), but not fun stuff like GADTs, recursion schemes, etc. We sometimes end up in generics hell, but I try to minimise those as much as possible.

Some things off the top of my head...

• Polymorphic traits are not ad-hoc like Haskell
  • You can't just make IEnumerable<A> into a monad/applicative/functor
  • The reason for this is that the traits only work when the data-type you're embellishing derives from K<F, A>
  • K<F, A> is f a in Haskell
• Polymorphic traits work well where we don't apply the final argument (like functors). But leaving off multiple arguments (like bifunctors), is still not that elegant. I'm experimenting with different approaches. I mean, it works, but not well enough.
  • To see what I mean, have a look at the trait-implementations for Either.
  • For now avoid Bifunctor, it's likely to change before RTM
• The trait-implementation types (so Option for data-type Option<A>, for example) implement multiple traits. And you can only have one of them.
  • So, unlike Haskell where you can create instance implementations with per-instance constraints, all constraints must exist for all trait-implementations.
  • This is most problematic for MonadIO as it means the type system doesn't follow the stack down automatically.
  • To solve this every Monad is also a MonadIO - not elegant and not how I want it, but the only way this works is if you provide an override for LiftIO in your trait-implementation class. For any monad-transformer stacks without the override, you will get the default implementation, which is to throw an exception. I figure an exception to let you know you haven't implemented LiftIO is better than not having that support at all.
  • This issue also limits the set capabilities that the standard set of monad-transformers can flow through the stack (so, if you want MonoidK (Alternative) to flow through then every transformer in the stack needs to implement it, it can't be discovered ad-hoc when the base-monad is a MonoidK.
  • As a compromise I've made all transformers implement SemigroupK, which means the base-monad needs to implement SemigroupK if you want to use it with the built-in transformers. Again, not ideal, but gets some of the most useful functionality of a transformer stack.
  • I'm trying to think of cunning (type safe) ways around this, but nothing has come to mind yet.
• The traits folder will have a lot of familiar types in there. The folders are structured in a consistent way:
  • NAME.Trait - the trait-definition (interface)
  • NAME.Module - this is where the common functions like pure, apply, map, sit. For example: Applicative.pure(x)
  • NAME.Extensions - extension methods that implement the traits for K<F, A>, types
  • NAME.Prelude - like the NAME.Module but in the Prelude, so available without the qualifying name
  • NAME.Laws - some traits have laws tests. So, FunctorLaws.assert and FunctorLaws.validate are there to test that your trait-implementations follow the rules (useful for unit tests)
• The IO monad is almost the same as Haskell's IO monad, but it also tracks resources through use and release and threads the CancelllationToken through (like a reader monad threads its environment)
• Eff<A> isn't significantly different from IO<A> atm. It also catches exceptions and turns the result into a Fin<A>, whereas IO<A> lets exceptions throw. Eff<RT, A> is the genuine improvement over IO<A>, as it supports the runtime injection.
• Parser<A> is a clone of Parsec, but when I wrote it C# didn't have static interface methods, so I couldn't build a ParserT<M, A>. My plan is to do a clone of Megaparsec, but that's not yet available. So, parsing is only parsing, not parsing with additional effects.
• Sequence is problematic for C# to infer the underlying nested traits, so if you need Sequence (and C# can't figure it out) use Traverse(identity) instead

That's all that's coming to mind right now, but it is hopefully of some use!

You’re doing gods work! Haha

Some people consider I'm doing the devil's work! :D