StricterLabelledFieldSyntax

[Simon Marlow]

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 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
>
> _______________________________________________
> Haskell-prime mailing list
> Haskell-prime at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-prime