Hi
Thinking on the semantic issue for the moment:
Can you use (<-) outside of a do block?
b >> f (<- a)
What are the semantics of
do b >> f (<- a)
where does the evaluation of a get lifted to?
Given:
if (<- a) then f (<- b) else g (<- c)
Do b and c both get monadic bindings regardless of a?
if (<- a) then do f (<- b) else g (<- c)
Does this change to make b bound inside the then, but c bound outside?
Does this then violate the rule that do x == x
Can you combine let and do?
do let x = (<- a)
f x
Our "best guess" is that all monadic bindings get floated to the
previous line of the innermost do block, in left-to-right order.
Monadic expressions in let statements are allowed. Outside a do block,
monadic subexpressions are banned.
Despite all these complications, it's still a great idea, and would be
lovely to have!
Thanks
Neil and Tom
On 8/3/07, Neil Mitchell <[EMAIL PROTECTED]> wrote:
> Hi
>
> Perhaps we need to cool this thread down a little bit, and refocus. I
> personally choose never to use ++ as anything but a statement, since
> my brain works that way. Other people find different things natural,
> so can pick what they choose. The one thing you can guarantee is that
> discussing it isn't going to result in anyone changing their opinion!
>
> The thread started out on monad subexpressions, with request for
> helpful thoughts as to what could be done with them, and how we can
> treat them syntactically. Does anyone have any further thoughts on the
> syntax? We started with 4 suggestions, and as far as I can tell, are
> left with only one (<- ...). This is the time for people to have new
> and clever thoughts, and possibly shape the future of (what I think)
> will be a very commonly used Haskell syntax.
>
> For the record, my comments on (<- ...) where not objections, but
> merely "thoughts out loud", and I could certainly see myself using
> that syntax in a day to day basis.
>
> Thanks
>
> Neil
>
>
>
> On 8/3/07, Mirko Rahn <[EMAIL PROTECTED]> wrote:
> >
> > >>> rewrite *p++=*q++ in haskell?
> >
> > > it's one of C idioms. probably, you don't have enough C experience to
> > > understand it :)
> >
> > Maybe, but how can *you* understand it, when the standard is vague about it?
> >
> > It could be
> >
> > A: *p=*q; p+=1; q+=1;
> > B: *p=*q; q+=1; p+=1;
> > C: tp=p; tq=q; p+=1; q+=1; *tp=*tq;
> >
> > ...and so on. Which is the "right" version?
> >
> > > result is that currently C code rewritten in Haskell becomes much
> > > larger and less readable.
> >
> > Larger should not be that issue and readability depends on the reader as
> > your C example shows. Some Haskellers would very quickly recognize some
> > common idioms, where others need some help...
> >
> > /BR
> >
> > --
> > -- Mirko Rahn -- Tel +49-721 608 7504 --
> > --- http://liinwww.ira.uka.de/~rahn/ ---
> > _______________________________________________
> > Haskell-Cafe mailing list
> > Haskell-Cafe@haskell.org
> > http://www.haskell.org/mailman/listinfo/haskell-cafe
> >
>
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
