$ do?

Quick question:

Why do I need the $ in the following bits of code?

...
main = withSocketsDo $ do --do something with sockets

...
foo = fromMaybe 0 $ do --do something in the maybe monad

I don't see (after admittedly only a minute or so thinking about it) where any grammar ambiguities would be if 'do' had an implicit $ in front of it:

...
foo = fromMaybe 0 do --do something in maybe

Though now that I've written it down, that is hard for me to visually parse at a glance. I'm still curious though.

Hi Jonathan, it's not clear whether you ask how this implies from the standard or what the rationale of such syntax is. Regarding the former, there are two distinct syntactic categories in Haskell: lexp and aexp. aexp produces all the constructs that can be used as function arguments and does not include do expressions. lexp is more broad and produces do expressions as well. Next look at these productions to see the difference between function application and operator application (sections 3.3 and 3.4 of 2010 report): fexp → [fexp] aexp inﬁxexp → lexp qop inﬁxexp Regarding the rationale, I'm not so sure and I'd like to hear an explanation from someone competent. But I assume it has something to do with the fact that if you supply a 'do' argument, you cannot supply any more arguments (because 'do' extends to the right as far as possible). Not that I'm convinced that it is a valid reason to prohibit such construct. -- Roman I. Cheplyaka :: http://ro-che.info/ Don't worry what people think, they don't do it very often.

Brandon Moore

16 Dec 16 Dec

1:31 a.m.

...

From: Roman Cheplyaka Sent: Wed, December 15, 2010 1:36:55 AM

* Jonathan Geddes [2010-12-14 19:59:14-0700]

...
Quick question:

Why do I need the $ in the following bits of code?

...
main = withSocketsDo $ do --do something with sockets

...
foo = fromMaybe 0 $ do --do something in the maybe monad

I don't see (after admittedly only a minute or so thinking about it) where any grammar ambiguities would be if 'do' had an implicit $ in front of it:

...
foo = fromMaybe 0 do --do something in maybe

Though now that I've written it down, that is hard for me to visually parse at a glance. I'm still curious though.

Hi Jonathan,

it's not clear whether you ask how this implies from the standard or what the rationale of such syntax is.

Regarding the former, there are two distinct syntactic categories in Haskell: lexp and aexp. aexp produces all the constructs that can be used as function arguments and does not include do expressions. lexp is more broad and produces do expressions as well. Next look at these productions to see the difference between function application and operator application (sections 3.3 and 3.4 of 2010 report):

fexp → [fexp] aexp

inﬁxexp → lexp qop inﬁxexp

Regarding the rationale, I'm not so sure and I'd like to hear an explanation from someone competent. But I assume it has something to do with the fact that if you supply a 'do' argument, you cannot supply any more arguments (because 'do' extends to the right as far as possible). Not that I'm convinced that it is a valid reason to prohibit such construct.

Years ago, I built GHC with a modified grammar including do and lambdas as aexp. It seemed to work. There were certainly conflicts reported by Happy, but examples seemed to work nicely and I couldn't think of any actual ambiguity. Brandon

Christian Maeder

7:45 a.m.

Am 15.12.2010 08:36, schrieb Roman Cheplyaka:

...

* Jonathan Geddes [2010-12-14 19:59:14-0700]

...
Quick question:

Why do I need the $ in the following bits of code?

...
main = withSocketsDo $ do --do something with sockets

...
foo = fromMaybe 0 $ do --do something in the maybe monad

I don't see (after admittedly only a minute or so thinking about it) where any grammar ambiguities would be if 'do' had an implicit $ in front of it:

...
foo = fromMaybe 0 do --do something in maybe

Though now that I've written it down, that is hard for me to visually parse at a glance. I'm still curious though.

Hi Jonathan,

it's not clear whether you ask how this implies from the standard or what the rationale of such syntax is.

Regarding the former, there are two distinct syntactic categories in Haskell: lexp and aexp. aexp produces all the constructs that can be used as function arguments and does not include do expressions. lexp is more broad and produces do expressions as well. Next look at these productions to see the difference between function application and operator application (sections 3.3 and 3.4 of 2010 report):

fexp → [fexp] aexp

inﬁxexp → lexp qop inﬁxexp

Regarding the rationale, I'm not so sure and I'd like to hear an explanation from someone competent. But I assume it has something to do with the fact that if you supply a 'do' argument, you cannot supply any more arguments (because 'do' extends to the right as far as possible). Not that I'm convinced that it is a valid reason to prohibit such construct.

I made such a proposal 3 years ago, without much feedback. http://www.haskell.org/pipermail/haskell-cafe/2007-July/028203.html Of course, you can supply more arguments, because "do", "let" and "case" will be terminated by layout. This is not true for "\" (lambda) and if-then-else, though. HTH Christian

Brandon S Allbery KF8NH

22 Dec 22 Dec

9:24 p.m.

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12/15/10 02:36 , Roman Cheplyaka wrote:

...

Regarding the rationale, I'm not so sure and I'd like to hear an explanation from someone competent. But I assume it has something to do with the fact that if you supply a 'do' argument, you cannot supply any more arguments (because 'do' extends to the right as far as possible). Not that I'm convinced that it is a valid reason to prohibit such construct.

Hm? do {...} would work, as would using indentation per usual layout rules (the next argument would be indented no farther than the "do"). It'd certainly be more confusing to read, though. - -- brandon s. allbery [linux,solaris,freebsd,perl] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.10 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk0SsvUACgkQIn7hlCsL25XM6wCcDvu9G3fc9M5Vv6d2EKZ64X8t k7YAn0hvoyq0KpmAAEyAD4HIWX8HsMTY =11UF -----END PGP SIGNATURE-----

5265

Age (days ago)

5273

Last active (days ago)

List overview

Download

4 comments

5 participants

participants (5)

Brandon Moore
Brandon S Allbery KF8NH
Christian Maeder
Jonathan Geddes
Roman Cheplyaka

$ do?

Jonathan Geddes

Roman Cheplyaka

Brandon Moore

Christian Maeder

Brandon S Allbery KF8NH

tags

participants (5)