Translating from Haskell to C# : IO action on Map values

[augyg]

Hello!

I am C# noob, Haskell intermediate, relative to the cool concepts in this library, ie. no experience with Effect Systems in Haskell.

I know that in Haskell I have said many times, I want to apply an (a -> m b) action on a (Map k a) and I've done it like this:

forM_ (Map.toList byUser) $ \(user, value :: Msg)) -> do
    f value 
where
    f :: a -> m b

I typically use this as a crappy one size fits all solution to a number of problems I come across and perhaps it is not even the way to go? I can't seem to find a ForM equivalent.

Should I go with an fmap then sequence? sequenceA $ fmap someEffect vals . Maybe I'm best off using TraverseM ?

Or am I just way off? Perhaps my difficulty stems from a lack of understanding the relationship between 'Task' and 'Eff'.

The C# code in question that is needing to change is:

    private static async Task<Map<(string, string, string), Lst<AttachmentContents>>> ScanNewMessagesForAttachments(string accessToken, Lst<string> mostRecent50)
    {
        Lst<MailMessage> unread = await GetUnread(mostRecent50, accessToken, countBy_config);
        Lst<MailMessage> unreadsWithAttachment = unread.Filter(u => u.HasAttachments);
        return await GetUnreadAttachments(accessToken, unreadsWithAttachment);
    }

(string,string,string) represents email info and is a key to the list of attachments for said email.

In my attempt to be functional in C# I used Filter (again: C# noob) and realized that I'm not returning the information about emails with no attachments and thus I never track elsewhere that emails with no attachment have been read.

I can see a band-aid solution to do another filter (!u.HasAttachments) and then Merge results but I am clearly struggling to translate basics from Haskell to C# and so this seems like a good question to crack open my mind.

[louthy]

(a -> m b) is obviously bind (monad bind) and as you demonstrate, by calling toList, Map k a isn't a monad. And neither is it a monad in language-ext either. In language-ext, if you use Map<K, A> or HashMap<K, A> then you can call:

  map.ToSeq();      // Lazy memoising sequence
  map.ToIterable(); // Lazy non-memoising sequence
  map.ToLst();      // Non-lazy sequence

With regards to mapM_ and forM_ that sequence foldable monadic actions. You can use this:

public static class YourPrelude
{
    public static K<M, Unit> forM<T, M, A, B>(K<T, A> ta, Func<A, K<M, B>> f)
        where M : Monad<M>
        where T : Foldable<T> =>
        ta.Fold(pure<M, Unit>(unit), x => k => f(x).Bind(_ => k));
}

Or, create an extension method:

public static class FoldableMonadExtensions
{
    public static K<M, Unit> ForM<T, M, A, B>(this K<T, A> ta, Func<A, K<M, B>> f)
        where M : Monad<M>
        where T : Foldable<T> =>
        YourPrelude.forM(ta, f);
}

I will add them to an upcoming release, but I'm taking a small break from language-ext right now.

In terms of mapM and forM, that's just traverse. Either use: Traversable.traverse for applicative traversal or monadic Traversable.traverseM (which is pretty close to forM), or their equivalent extension methods.

By the way, if you're not on the v5-beta then I'd advise moving to it, because that's where all the support for traits are (type-classes)

Just to be clear Task is nothing to do with this library and is part of the .NET library ecosystem. It is a promise type. It has none of the purity guarantees that IO or Eff have (because it doesn't represent a computation, it represents a computation which then memoises its result, this is obviously problematic in terms of referential transparency).

Also the whole async / await machinery isn't properly composable, so will back you into awkward corners. I prefer to use LINQ and IO or Eff and only evaluate an operation to a Task at the edges of the application.

I can see a band-aid solution to do another filter (!u.HasAttachments)

First, I'd advise using Seq rather than Lst. Seq is much more efficient generally, it just doesn't allow for insertions (just allows cons and add). Second, we support .Partition which, like .Filter, takes a predicate. However, it returns two sequences, one for the true result, one for the false result.

If you're just learning C# and language-ext, I'd suggest taking a look at some of the samples:

• CardGame - what's quite nice about this is it shows how minimal C# can look when following pure-FP techniques.
• EffectsExamples - this shows what I mean about using Eff throughout the application and only running it in Main (like IO in Haskell), but has lots of other useful examples. You see no Task or async/await anywhere.
• Newsletter - a real-world blog newsletter sending application. It completely abstracts away from the running monads and just works with effect traits. This is the most extreme abstraction we can do with C# (and is a bit much for most use-cases), but it also shows how async/await goes away, apart from in the encapsulated effects

One major difference in how you write functional-C# compared to Haskell is that you'll lean on LINQ in C# much more than you lean on do notation in Haskell. In Haskell we can leverage operators and exceptional type inference, but that's not quite as nice in C# (although I do my best to make it as elegant as I can!)

LINQ is a bit more forgiving than the regular function invocation in C#, so it's easier to write out LINQ expressions (when leveraging monadic effects) than it is to write overly terse operator leveraging expressions.

[augyg]

One major difference in how you write functional-C# compared to Haskell is that you'll lean on LINQ in C# much more than you lean on do notation in Haskell. In Haskell we can leverage operators and exceptional type inference, but that's not quite as nice in C# (although I do my best to make it as elegant as I can!)

I'm starting to recognize that, I was wondering if there was a similar motivation to using Effects systems with extensible Runtimes? I haven't reached for Monad transformers yet but I can see that being a challenge to extend in comparison to using Has/Traits on an effects system Runtime. Was quite fascinated by the implementation of Newsletter.

I was also purely curious about if there are any intentionally borrowed ideas from Rust? IEnumerable/Iterable seem very similar to the Iter trait

Also thank you for these examples, this has helped clean up my mental mess of strategies.

[louthy]

I'm starting to recognize that, I was wondering if there was a similar motivation to using Effects systems with extensible Runtimes? I haven't reached for Monad transformers yet but I can see that being a challenge to extend in comparison to using Has/Traits on an effects system Runtime. Was quite fascinated by the implementation of Newsletter.

The key motivation was to be able to 'wrap up' .NET OO crap into these extensible runtimes that would then behave in a pure-FP way and would actually be composable, unlike most .NET ecosystem libraries. And then, be able to swap out implementations for test-runtimes, or alternatives, or whatever. Doing dependency-injection robustly in a type-safe way, without any hacks or additional tooling.

Of the approaches mentioned (K style effects, Eff effects, and monad-transformers): Each has its pros and cons...

K style effects

As seen in the Newsletter sample

There's no doubt that trait constraints on an M type and on the 'RT' type, with the Has, Local, and Mutates constraints, is extremely powerful and allows abstraction away from the underlying effect-type completely. It does however have a few issues:

• Because it relies on constraining the generic M parameter in K<M, A> type, we must work with the K type everywhere, and K is an interface. Interfaces cannot be used with operators or implicit/explicit conversions. That means no ability to do monadic actons: ma >> mb, or fallible catching: ma | @catch(...), or monoidal ma + mb, etc. you have to use ma.Combine(mb), .Catch(...), and the like. This is arguably more idiomatic, but makes for less elegant code overall.
• Flowing the constraints through the application is work. Depending on your point-of-view this is either "taking declarative coding too far", or "this is the whole point of declarative coding". Either way, it requires more effort to flow the constraints through your application. Where you sit on the 'declarative coding spectrum' will inform your decision.

Eff effects

As seen in the EffectsExamples sample

This is similar to the K effects in that we carry around the Has, Local, and Mutates constraints. But instead of using K<M, A> we use Eff<RT, A>. This gives us back our operators, but limits us entirely to one monadic type (Eff). So, if you run out of features (let's say you needed Writable functionality), well, tough. Unless you can find some way of baking it into the runtime.

This is a bit like using IO in Haskell, but with a few extra bells and whistles.

Monad transformers

As seen in the CardGame sample

With monad-transformers you tend to wrap a transformer-stack in a new type, like the Game<A> type in the CardGame sample. That's a StateT -> OptionT -> IO stack. In it's most minimal implementation you could write:

public record Game<A>(StateT<GameState, OptionT<IO>, A> runGame) : K<Game, A>;

That wraps the transformer-stack in a new type and derives from the K type.

Then the trait-implementations for the Game type:

public partial class Game :
    Deriving.Monad<Game, StateT<GameState, OptionT<IO>>>,
    Deriving.Choice<Game, StateT<GameState, OptionT<IO>>>,
    Deriving.Stateful<Game, StateT<GameState, OptionT<IO>>, GameState>,
    MonadIO<Game>
{
    public static K<StateT<GameState, OptionT<IO>>, A> Transform<A>(K<Game, A> fa) =>
        fa.As().runGame;

    public static K<Game, A> CoTransform<A>(K<StateT<GameState, OptionT<IO>>, A> fa) => 
        new Game<A>(fa.As());

    public static K<Game, A> LiftIO<A>(IO<A> ma) => 
        new Game<A>(StateT.liftIO<GameState, OptionT<IO>, A>(ma));
}

That leverages the new Deriving capability. It deals with proxying the trait APIs to the underlying implementation.

And then the downcast extension:

public static class GameExtensions
{
    public static Game<A> As<A>(this K<Game, A> ma) =>
        (Game<A>)ma;
}

That's all that's needed to wrap a monad-transformer stack and expose all of the capabilities of the underlying stack.

The cons are is that it's obviously then got all of its behaviours baked in and you'd probably want to create separate domain-based monads (like App<A>, Db<A>, etc.) for the various sub-domains in your app. That's ok, but less abstract than the K trait constraint based approach.

Also, there's a bit of typing to create a domain-monad. That's not too much of a con because normally you wouldn't need to create too many domain monads. Maybe 3 or 4 per project depending on how you want separate the concerns.

The pros are that you can add operators and various support module functions to make your life a little easier:

    public static implicit operator Game<A>(Pure<A> ma) =>
        Pure(ma.Value);

    public static implicit operator Game<A>(IO<A> ma) =>
        Game.liftIO(ma);

    public static implicit operator Game<A>(Option<A> ma) =>
        Game.lift(ma);

    public static Game<A> operator >>(Game<A> ma, K<Game, A> mb) =>
        ma.Bind(_ => mb);

    public static Game<A> operator >>(Game<A> ma, K<Game, Unit> mb) =>
        ma.Bind(x => mb.Map(_ => x));

    public static Game<A> operator >>(Game<A> ma, K<IO, A> mb) =>
        ma.Bind(_ => mb.As());

    public static Game<A> operator >>(Game<A> ma, K<IO, Unit> mb) =>
        ma.Bind(x => mb.As().Map(_ => x));

Which allows for code like this:

public static Game<Unit> play =>
    Display.askPlayerNames >>
    enterPlayerNames       >>
    Display.introduction   >>
    Deck.shuffle           >>
    playHands;

Another pro is that, by wrapping up the transformer-stack, you can change the stack without changing the code that uses it (unless you're taking away functionality). So, if you needed to add something else to the stack then it would be relatively easy to do.

Building 'modules' around the type can also expand the core capabilities into more of an API. Which works well for domain monads, less well for general-purpose monads.

Arguably, the monad-transformer sample leads to slightly less declarative code, but easier for the average C# dev to read/understand. So, if you're in a team, then this might be easier to consume.

You can also mix and match the three approaches. Have more domain-based monads where you really want to create a specific subsystem (database access for example); write completely abstract code that uses the Has constraints; and have Eff based code for more general purpose effects, or whatever.

There's no right answer really, it's preference, and trade-offs.

I was also purely curious about if there are any intentionally borrowed ideas from Rust? IEnumerable/Iterable seem very similar to the Iter trait

I've actually never used Rust, so no. But I have liberally stolen ideas from other languages. Including: F#, Haskell, PureScript, Erlang, and Clojure (probably others, but those are what spring to mind). Rust is on the list to look at, because there are ideas around linear and affine types that can be achieved in C# too. It could lead to some optimisations that I haven't thought of.