On 27/07/2011, at 22:38 , Alexander Shpilkin wrote:
> On Wed, Jul 27, 2011 at 6:13 AM, Ben Lippmeier <[email protected]> wrote:
>> Yes, that is a problem. I was thinking we we should use plain 'do' for the
>> imperative do, and 'mdo' for the monadic one, but I didn't finish
>> implementing this. I'm open to suggestions.
>
> I'd call the imperative one "seq" and the monadic one "do", but this
> is not so "natural-language-like" or whatever. Don't know really. (May
> still implement either of these in the meantime.)
But Haskell already uses "seq" to mean something quite different. I'd also
expect uses of 'do' to be more frequent than 'mdo', so the more frequent one
should get the shortest name.
>>> It's
>>> not obvious what was intented from the current parser; it even allows
>>> (or rather would allow if parsing "x <- foo" really worked) "instance
>>> Monad Foo where { return <- undefined }" which is complete nonsense.
>>
>> This is actually ok, because 'return' isn't a keyword. The return function
>> is defined as a regular binding, and presuming you allow variable shadowing
>> you can redefine its meaning locally.
>
> Sure; it is the (<-) binding in an instance declaration which is strange.
Ah, now I see, I misread it the first time. Yeah, that's pretty bad :-)
>> Whether we allow a monadic bind as the last statement in a do-block is a
>> separate decision.
>
> Why would we want to?
I remember once finding it annoying that I couldn't end a do-block with a
binding. I wouldn't write production code like this, but it can be useful
during debugging when you just want to comment out something quickly to check
what happens. If you comment out the last expression in a block, and the second
last one is a binding, then Haskell complains. It's only a minor thing, and I
haven't been bothered about it recently.
Ben.
--
Disciple-Cafe mailing list
http://groups.google.com/group/disciple-cafe
