StricterLabelledFieldSyntax

[Simon Peyton-Jones]

Personally I hate the fact that
	f Z {x=3}
parses as 
	f (Z {a=3})
because even though (as Iavor says) there is only one function application involved, it *looks* as if there are two.

Equally personally, I think that the presence or absence of white space is a powerful signal to programmers, and it's a shame to deny ourselves use of it.  So I'd be quite happy with *requiring* there to be no space, thus Z{ x=3 }.  If that's tricky to lex, so be it.  (Though a token "BRACE_WITH_NO_PRECEDING_WHITESPACE" might do the job.)  But this would be a very non-backward-compatible change.

Simon

| -----Original Message-----
| From: haskell-prime-bounces at haskell.org [mailto:haskell-prime-
| bounces at haskell.org] On Behalf Of Ian Lynagh
| Sent: 26 July 2009 21:53
| To: haskell-prime at haskell.org
| Subject: Re: StricterLabelledFieldSyntax
| 
| On Sun, Jul 26, 2009 at 10:16:28PM +0300, Iavor Diatchki wrote:
| >
| > On Sun, Jul 26, 2009 at 10:01 PM, Isaac
| > Dupree<ml at isaac.cedarswampstudios.org> wrote:
| > > Iavor Diatchki wrote:
| > >>
| > >> I am strongly against this change.  The record notation works just
| > >> fine and has been doing so for a long time.  The notation is really
| > >> not that confusing and, given how records work in Haskell, makes
| > >> perfect sense (and the notation has nothing to do with the precedence
| > >> of application because there are no applications involved).  In short,
| > >> I am not sure what problem is addressed by this change, while a very
| > >> real problem (backwards incompatibility) would be introduced.
| > >> -Iavor
| > >
| > > a different approach to things that look funny, has been to implement a
| > > warning message in GHC.  Would that be a good alternative?
| >
| > Not for me. I use the notation as is, and so my code would start
| > generating warnings without any valid reason, I think.  What would
| > such a warning warn against, anyway?
| 
| For context, I looked at the alsa package. All of the (roughly 10)
| would-be-rejected cases looked like one of the two examples below. I
| don't really have anything new to say: Some people think these are
| clear, others find them confusing. Hopefully we'll find a consensus and
| make a decision.
| 
| 
| throwAlsa :: String -> Errno -> IO a
| throwAlsa fun err = do d <- strerror err
|                        throwDyn AlsaException
|                          { exception_location = fun
|                          , exception_description = d
|                          , exception_code = err
|                          }
| 
|   peek p      = do cl <- #{peek snd_seq_addr_t, client} p
|                    po <- #{peek snd_seq_addr_t, port} p
|                    return Addr { addr_client = cl, addr_port = po }
| 
| 
| Thanks
| Ian
| 
| _______________________________________________
| Haskell-prime mailing list
| Haskell-prime at haskell.org
| http://www.haskell.org/mailman/listinfo/haskell-prime