StricterLabelledFieldSyntax

[Iavor Diatchki]

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