Re: StricterLabelledFieldSyntax

Hello, There are some examples where the current notation is nicer (subjectively so, of course :-) with the white space. Mostly, when the record fields do not fit on a single line. I tend to write things like this: ParseError { errorPosition = .. , errorDescription = .. } alternatively: ParseError { errorPosition = .., errorDescription = .. } I think that it would be very odd if these did not work because the brace had to be next to the constructor without white space. The only alternative I can see would be to have _two_ different notations for creating records one with the space that requires parens, and one without that does not require parens but (at least to me) this looks like a cludge, and is much more complex than the current situation. -Iavor On Sat, Aug 1, 2009 at 2:58 PM, Simon Peyton-Jones wrote:

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@haskell.org [mailto:haskell-prime- | bounces@haskell.org] On Behalf Of Ian Lynagh | Sent: 26 July 2009 21:53 | To: haskell-prime@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 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@haskell.org | http://www.haskell.org/mailman/listinfo/haskell-prime

_______________________________________________ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime