[Haskell] Mixing monadic and non-monadic functions

[Frederik Eaton]

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

Reader (+1) + Reader (+4) == Reader (\x -> 2*x+5)

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
`ap`s:

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

print ("a: " ++ readLn ++ "\nb: " ++ readLn)

two lines are read and then printed. Does anybody for a moment
question what order the lines should be read in?

Frederik



On Tue, Mar 23, 2004 at 12:55:56PM -0500, Sean E. Russell wrote:
> On Tuesday 23 March 2004 11:36, Graham Klyne wrote:
> > I think you're a rather stuck with the "temporary variables" (which they're
> > not really), but it might be possible to hide some of the untidiness in an
> > auxiliary monadic function.
> 
> That seems to be the common suggestion: write my own visitors.
> 
> I'm just surprised that there isn't a more elegant mechanism for getting 
> interoperability between monadic and non-monadic functions.  The current 
> state of affairs just seems awkward.  
> 
> [Warning: quasi-rant]
> 
> Caveat: I'm not smart enough, and I don't know enough, to criticize Haskell, 
> so please don't misconstrue my comments.  To quote Einstein: "When I'm asking 
> simple questions and I'm getting simple answers, I'm talking to God."  I 
> simply mistrust, and therefore question, systems where simple things are 
> overly involved.
> 
> The standard explaination about why monads are so troublesome always sounds 
> like an excuse to me.  We have monads, because they allow side-effects.  Ok.  
> If programs that used side effects were uncommon, I'd be fine with them being 
> troublesome -- but they aren't.  Maybe it is just me, but my Haskell programs 
> invariably develop a need for side effects within a few tens of lines of 
> code, whether IO, Maybe, or whatnot.  And I can't help but think that 
> language support to make dealing with monads easier -- that is, to integrate 
> monads with the rest of the language, so as to alleviate the need for 
> constant lifting -- would be a Good Thing.
> 
> Hmmm.  Could I say that Haskell requires "heavy lifting"?
> 
> -- 
> ### SER   
> ### Deutsch|Esperanto|Francaise|Linux|XML|Java|Ruby|Aikido
> ### http://www.germane-software.com/~ser  jabber.com:ser  ICQ:83578737 
> ### GPG: http://www.germane-software.com/~ser/Security/ser_public.gpg



> _______________________________________________
> Haskell mailing list
> Haskell at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell


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