Re: [Haskell-cafe] Re: monad subexpressions

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 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 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