Frederik Eaton frederik at a5.repetae.net
Thu Sep 8 16:30:51 EDT 2005

On Thu, Sep 08, 2005 at 09:30:34AM -0700, Scherrer, Chad wrote:
> One of Mark Jones's articles suggests something like
>
> class Plus a b c | a b -> c where
>   (+) :: a -> b -> c
>
> Would
>
> instance (Plus a b c, Monad m) => Plus (m a) (m b) (m c) where
>   mx + my = do x <- mx
>                y <- my
>                return (x + y)
>
> do what you're looking for?

I'm not sure exactly what you have in mind. Obviously I want something
that applies to all functions, with any number of arguments, and not
just (+). Furthermore, it should handle cases like 1+[2,3] where only
one value is monadic. Keean Schupke's suggestion sounds more likely to
be useful, but I'm still reading it. In any case, a minimum of

Frederik

> ------------------------------------------------------------------
> Original message:
>
> Hi,
>
> Sean's comment (yeah, it was like a billion years ago, just catching
> up) is something that I've often thought myself.
>
> I want the type system to be able to do "automatic lifting" of monads,
> i.e., since [] is a monad, I should be able to write the following:
>
> [1,2]+[3,4]
>
> and have it interpreted as "do {a<-[1,2]; b<-[3,4]; return (a+b)}".
>
> Also, I would have
>
>
> The point I want to make is that this is much more general than IO or
> monads! I think we all understand intuitively what mathematicians mean
> when they add two sets
>
> {1,2}+{3,4}      (i.e. { x+y | x\in {1,2}, y\in {3,4}})
>
> or when they add functions
>
> (f+g)(x)         where f(x)=x+1 and g(x)=x+4
>
> So "automatic lifting" is a feature which is very simple to describe,
> but which gives both of these notations their intuitive mathematical
> meaning - not to mention making monadic code much tidier (who wants to
> spend their time naming variables which are only used once?). I think
> it deserves more attention.
>
> I agree that in its simplest incarnation, there is some ugliness: the
> order in which the values in the arguments are extracted from their
> monads could be said to be arbitrary. Personally, I do not think that
> this in itself is a reason to reject the concept. Because of currying,
> the order of function arguments is already important in Haskell. If
> you think of the proposed operation not as lifting, but as inserting
> aps:
>
> return f ap x1 ap ... ap xn
>
> then the ordering problem doesn't seem like such a big deal. I mean,
> what other order does one expect, than one in which the arguments are
> read in the same order that 'f' is applied to them?
>
> Although it is true that in most of the instances where this feature
> would be used, the order in which arguments are read from their monads
> will not matter; yet that does not change the fact that in cases where
> order *does* matter it's pretty damn easy to figure out what it will
> be. For instance, in
>
>
> two lines are read and then printed. Does anybody for a moment
> question what order the lines should be read in?
>
> Frederik
>
>

--
http://ofb.net/~frederik/