Von Samsung Mobile gesendet -------- Ursprüngliche Nachricht -------- Von: haskell-cafe-request@haskell.org Datum: 23.08.2013 11:36 (GMT+01:00) An: haskell-cafe@haskell.org Betreff: Haskell-Cafe Digest, Vol 120, Issue 35 Send Haskell-Cafe mailing list submissions to haskell-cafe@haskell.org To subscribe or unsubscribe via the World Wide Web, visit http://www.haskell.org/mailman/listinfo/haskell-cafe or, via email, send a message with subject or body 'help' to haskell-cafe-request@haskell.org You can reach the person managing the list at haskell-cafe-owner@haskell.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Haskell-Cafe digest..." Today's Topics:    1. Re: Yet Another Forkable Class (John ExFalso)    2. Re: Yet Another Forkable Class (suhorng Y)    3. Lifting strictness to types (Thiago Negri)    4. Re: Lifting strictness to types (Tom Ellis)    5. Re: Lifting strictness to types (Thiago Negri)    6. instance Alternative ZipList (Stefan Mehner)    7. Re: Lifting strictness to types (Bardur Arantsson)    8. Hoogle vs Hayoo (jabolopes@google.com)    9. Re: Hoogle vs Hayoo (Mateusz Kowalczyk)   10. Re: monoids induced by       Applicative/Alternative/Monad/MonadPlus? (Petr Pudl?k)   11. Re: Hoogle vs Hayoo (Johannes Waldmann)   12. Re: Yet Another Forkable Class (oleg@okmij.org)   13. Re: Hoogle vs Hayoo (Erik Hesselink)   14. Conduit : is it possible to write this function?       (Erik de Castro Lopo)   15. Re: Hoogle vs Hayoo (Daniel Trstenjak)   16. Re: Conduit : is it possible to write this function?       (Michael Snoyman)   17. typeclass constraints (TP)   18. Re: typeclass constraints (Adam Gundry) ---------------------------------------------------------------------- Message: 1 Date: Thu, 22 Aug 2013 15:50:23 +0100 From: John ExFalso <0slemi0@gmail.com> To: "Alberto G. Corona" <agocorona@gmail.com> Cc: "oleg@okmij.org" <oleg@okmij.org>, haskell-cafe <Haskell-cafe@haskell.org> Subject: Re: [Haskell-cafe] Yet Another Forkable Class Message-ID: <CAJEmqMj8Y7KoNVPS7x6zvvtkAmYheax9oigTPLLHDchfHde_pA@mail.gmail.com> Content-Type: text/plain; charset="iso-8859-1" To be honest I'm not so sure about these "effects"... Simply the fact that the Member class needs -XOverlappingInstances means that we cannot have duplicate or polymorphic effects. It will arbitrarily pick the first match in the former and fail to compile in the latter case. Furthermore I don't really understand the way open sums are implemented. These unions should be disjoint, but the way they're implemented in the paper they try to be "true" unions which cannot be done as that would need type equality (-XOverlappingInstances is a hack around this) A correct disjoint open sum would behave well with duplicate and polymorphic types in the type list. For example we should be able to project the open sum equivalent of Either String String into the second String but we cannot with the implementation in the paper. This means we need to ~index~ the type list instead of picking the result type and "trying for equality" with each entry. Something like this: http://lpaste.net/92069 Of course this is very inconvenient and simply replaces the monad transformers' lifts with a static index into the "effect" list. In general I think there is no convenient way of stacking effects that is also type safe. At some point we have to disambiguate which effect we are trying to use one way or the other. The implementation in the paper simply picks a heuristic and chooses the first effect that seems to match and discards the others. On 22 August 2013 12:15, Alberto G. Corona <agocorona@gmail.com> wrote:

The paper is very interesting:

http://www.cs.indiana.edu/~sabry/papers/exteff.pdf

It seems that the approach is mature enough and it is better in every way than monad transformers, while at the same time the syntax may become almost identical to MTL for many uses.

I only expect to see the library in Hackage with all the blessings, and with all the instances of the MTL classes in order to make the transition form monad transformers  to ExtEff as transparent as possible

2013/8/22 <oleg@okmij.org>

...

Perhaps effect libraries (there are several to choose from) could be a better answer to Fork effects than monad transformers. One lesson from the recent research in effects is that we should start thinking what effect we want to achieve rather than which monad transformer to use. Using ReaderT or StateT or something else is an implementation detail. Once we know what effect to achieve we can write a handler, or interpreter, to implement the desired operation on the World, obeying the desired equations. And we are done.

For example, with ExtEff library with which I'm more familiar, the Fork effect would take as an argument a computation that cannot throw any requests. That means that the parent has to provide interpreters for all child effects. It becomes trivially to implement:

...

Another example would be a child that should not be able to throw errors as opposed to the parent thread. It is possible to specify which errors will be allowed for the child thread (the ones that the parent will be willing to reflect and interpret). The rest of errors will be statically prohibited then.

...

instance (Protocol p) => Forkable (WebSockets p) (ReaderT (Sink p) IO) where      fork (ReaderT f) = liftIO . forkIO . f =<< getSink

This is a good illustration of too much implementation detail. Why do we need to know of (Sink p) as a Reader layer? Would it be clearer to define an Effect of sending to the socket? Computation's type will make it patent the computation is sending to the socket. The parent thread, before forking, has to provide a handler for that effect (and the handler will probably need a socket).

Defining a new class for each effect is possible but not needed at all. With monad transformers, a class per effect is meant to hide the ordering of transformer layers in a monad transformer stack. Effect libraries abstract over the implementation details out of the box. Crutches -- extra classes -- are unnecessary. We can start by writing handlers on a case-by-case basis. Generalization, if any, we'll be easier to see. From my experience, generalizing from concrete cases is easier than trying to write a (too) general code at the outset. Way too often, as I read and saw, code that is meant to be reusable ends up hardly usable.

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

-- Alberto.

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe