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<simo...@microsoft.com> 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-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
