5 ms·

https://github.com/scalaz/scalaz https://github.com/scalaz/scalaz Monad Transformers for one. Traverse/Sequence are another super common (amazing) pattern tha

by runT1ME 11y ago

https://github.com/scalaz/scalaz https://github.com/scalaz/scalaz Monad Transformers for one. Traverse/Sequence are another super common (amazing) pattern that requires abstracting over types. http://eed3si9n.com/learning-scalaz-day12 http://eed3si9n.com/learning-scalaz-day12 is a nice tutorial series on it.

louthy 11y ago
Monad transformers in C# [1] (but yes, only works with the monads in the library) [1] https://github.com/louthy/language-ext/blob/master/LanguageExt.Tests/OptionTTests.cs https://github.com/louthy/language-ext/blob/master/LanguageE...
daxfohl 11y ago
Ah, light bulb moment (perhaps). So in F# I've been using specialized asyncSeq and asyncMaybe libraries. With monad transformers (and thus HKT's), would those come largely for free? And you could traverse a list<maybe<list<_>> combo like [Some [Some [1; 2]; None; Some [3]]; None; Some [None; Some [4]]] with no more difficulty than a regular list-of-lists?
- runT1ME 11y ago
  Exactly! You can also write a generic "sequence" over a list, for instance, so that any 'monad' (task/future, maybe/option, state, either/disjunction etc.) can 'swap places'. So your List<Future<A>> can become Future<List<A>>. But you only need to write it once. Then it doesn't matter what the inner type of the List is, as long as it's a monad (applicative, really, but all monads are applicatives).
  - daxfohl 11y ago
    Crazy, I'd always considered monad transformers a sore thumb on, well, all that stuff. The fact that monads weren't enough but then you had to go reproduce all that stuff in monad transformers as well. The whole thing just reeked of code duplication and bad smells so I didn't really look into it further. Now looking at the Scalaz impl, the transformers are actually the core thing, and monads themselves are just transformers over Identity. So it all fits and isn't redundant. Certainly changes a lot of perspective.
    - daxfohl 11y ago
      That said, I'd still put LINQ as 99% of "the deal" per the original comment. The extra abstractions allowed by HKT's, while "necessary" mathematically, still only save me about 1% of the work required to implement asyncSeq and asyncMaybe, and in 15 years of pro experience those are the only real uses of HKT's I've ever had the need for.

by runT1ME 11y ago

louthy 11y ago

Monad transformers in C# [1] (but yes, only works with the monads in the library) [1] https://github.com/louthy/language-ext/blob/master/LanguageExt.Tests/OptionTTests.cs https://github.com/louthy/language-ext/blob/master/LanguageE...

daxfohl 11y ago

Ah, light bulb moment (perhaps). So in F# I've been using specialized asyncSeq and asyncMaybe libraries. With monad transformers (and thus HKT's), would those come largely for free? And you could traverse a list<maybe<list<_>> combo like [Some [Some [1; 2]; None; Some [3]]; None; Some [None; Some [4]]] with no more difficulty than a regular list-of-lists?

runT1ME 11y ago
Exactly! You can also write a generic "sequence" over a list, for instance, so that any 'monad' (task/future, maybe/option, state, either/disjunction etc.) can 'swap places'. So your List<Future<A>> can become Future<List<A>>. But you only need to write it once. Then it doesn't matter what the inner type of the List is, as long as it's a monad (applicative, really, but all monads are applicatives).
- daxfohl 11y ago
  Crazy, I'd always considered monad transformers a sore thumb on, well, all that stuff. The fact that monads weren't enough but then you had to go reproduce all that stuff in monad transformers as well. The whole thing just reeked of code duplication and bad smells so I didn't really look into it further. Now looking at the Scalaz impl, the transformers are actually the core thing, and monads themselves are just transformers over Identity. So it all fits and isn't redundant. Certainly changes a lot of perspective.
  - daxfohl 11y ago
    That said, I'd still put LINQ as 99% of "the deal" per the original comment. The extra abstractions allowed by HKT's, while "necessary" mathematically, still only save me about 1% of the work required to implement asyncSeq and asyncMaybe, and in 15 years of pro experience those are the only real uses of HKT's I've ever had the need for.