Re: StricterLabelledFieldSyntax

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-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