Hi,
I'm fairly new to Haskell and recently came across some programming
tricks for reducing monadic overhead, and am wondering what
higher-level concepts they map to. It would be great to get some
pointers to related work.
Background:
I'm a graduate student whose research interests include
On Nov 15, 2010, at 9:43 AM, Ling Yang wrote:
Specifically: There are some DSLs that can be largely expressed as
monads,
that inherently play nicely with expressions on non-monadic values.
This, to me, is a big hint that applicative functors could be useful.
Every monad is an
On Mon, Nov 15, 2010 at 12:43 PM, Ling Yang ly...@cs.stanford.edu wrote:
Specifically: There are some DSLs that can be largely expressed as monads,
that inherently play nicely with expressions on non-monadic values.
We'd like to use the functions that already work on the non-monadic
values for
This, to me, is a big hint that applicative functors could be useful.
Indeed, the ideas here also apply to applicative functors; it is just the
lifting primitives that will be different; instead of having liftMN, we can
use $ and * to lift the functions. We could have done this for Num and
See my reply to Alex's post for my perspective on how this relates to
applicative functors, reproduced here:
This, to me, is a big hint that applicative functors could be useful.
Indeed, the ideas here also apply to applicative functors; it is just the
lifting primitives that will be
On Mon, Nov 15, 2010 at 6:43 PM, Ling Yang ly...@cs.stanford.edu wrote:
...
One alternate way of doing this, however, is instancing the
typeclasses of the ordinary values with their monadic versions:
instance (Num a) = Num (Prob a) where
(+) = liftM2 (+)
(*) = liftM2 (*)
I like your autolifting stuff, and the runnable concept.
2010/11/15 Ling Yang ly...@cs.stanford.edu
See my reply to Alex's post for my perspective on how this relates to
applicative functors, reproduced here:
This, to me, is a big hint that applicative functors could be useful.
Indeed,
