On 01/08/2009 12:58, 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.
On this point - I agree that whitespace-sensitive syntax presents no
problem to programmers, and is often quite natural. However, I think it
presents enough other problems that it should be avoided where possible.
I'm thinking of
- being friendly to automatic program generation
- being friendly to parsers, and tools that grok Haskell
- making code robust to modification that changes whitespace
- making the grammar (in the report) simpler
all of these things are hurt by whitespace-sensitive syntax. IMO, we
should think very carefully before introducing any.
Cheers,
Simon
Simon
| -----Original Message-----
| From: haskell-prime-boun...@haskell.org [mailto:haskell-prime-
| boun...@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<m...@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@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
_______________________________________________
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime
