[ghc-steering-committee] Records again

[Iavor Diatchki]

Personally, I am not thrilled about this proposal, and I am unlikely to use
it, if it is implemented.

As I said before, I am fine with accepting it, if others would find it
useful, as long as we have the option to not use it---
I realize I am in the minority here, but think Haskell's records actually
work pretty well as they are and I use them all the time
without significant problems.

As for the concrete design question: I agree that `f x.y` should mean `f
(x.y)`.

-Iavor











On Mon, Dec 16, 2019 at 3:48 PM Simon Peyton Jones via
ghc-steering-committee <ghc-steering-committee at haskell.org> wrote:

> Dear steering committee
>
> I am keen to prevent the record-syntax debate from spiralling outwards.
> This has happened before, and is the main reason Haskell has remained stuck
> with sub-standard records for so long.  So I'm playing a more active, even
> directive, shepherding role than usual.
>
> Vitaly, thanks for your response, but I continue to believe that we should
> accept some version of this proposal.   I can elaborate more if needed, but
> I think that most of the committee agrees with the direction of travel.
> (But please say if you want to join Vitaly in outright rejection.)
>
> Assuming that we want to accept some version, *I'd like to propose that
> we adopt the idea that `f r.x` means `f (r.x)`*, and not the record
> selection `(f r).x`, nor the function composition `(f r) . x`.
>
> Joachim floated the `(f r).x` idea recently and Richard supported him.  I
> consulted the authors who said "Interestingly, the very first version of
> the prototype implemented exactly that. That behaviour surprised the heck
> out of everyone (including you) and we were quickly and overwhelmingly
> convinced that it was the wrong parse and updated the proposal
> accordingly."  I had a long conversation with Richard, who (I think) finds
> both alternatives acceptable.
>
> I agree strongly with the authors; I think `(f r).x` would be horrible,
> and would vote against such a proposal.  So, in the interests of making
> progress, I recommend that we adopt the `f (r.x)` parse.   Talking to
> Richard I realise that a lot depends on your starting point:
>
>    1. I regard `M.N.x` and `r.x.y` as a single token, where `.` is
>    punctuation.  Space is always significant for dot; `M . x` is quite
>    different to `M.x`.  Another example is the unbounded enumeration `[Z ..]`
>    where you must put the space; if you write `[Z..]` you'll get the
>    dot-operator imported from module Z.
>
> From this point of view, Haskell's use of `(.)` as an infix operator for
> composition is an aberration.   And parsing `f r.x` as `f (r.x)` is
> consistent with our parse of `f M.x`.
>
>    1. An alternative point of view is to regard `(.)` as a fully fledged
>    operator, and all the stuff about qualified names, enumerations and so on,
>    as a sad aberration.  Under this point of view, record selection just makes
>    the aberration worse.
>
> I realise that one reason I want the `f (r.x)` parse so strongly is my
> previously-implicit espousal of (A); perhaps making that explicit will help
> frame the conversation.  I’m also very un-keen on making `r.x` illegal,
> which is another alternative in theory.
>
> TL;DR.  Does anyone (who wants to accept the proposal in some form)
> seriously oppose the `f (r.x)` parse for `f r.x`?  I hope that it'll be at
> least acceptable to everyone, and we can more on.
>
> Thanks
>
> Simon
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20191216/d5746421/attachment-0001.html>