[ghc-steering-committee] RecordDotSyntax: please express a view

[Spiwack, Arnaud]

I'm having most trouble forming an opinion on this.

Let me try to formulate my thoughts

This proposal solves

1. A dot syntax for record selector
2. A nested record update syntax
3. Shared record field names

This proposal doesn't address

4. Partial selection
5. Partial update

This proposal breaks

6. Type-changing record update
7. Polymorphic (rank 2+) fields

Does it balance out?

1. is nice, but honestly pretty trivial. The real reason for 1, though, is
to enable 3.
2. is pretty cool. When you need nested update, not having syntax for it is
pretty painful. It seems to be an oft repeated reason why Haskell records
“suck”. That being said, how many languages don't have nested update, and
of these do people complain about records “sucking”. As an example, Ocaml
doesn't have nested updates, and Ocaml programmers don't complain about
records. Still, pretty cool.
3. again a common complaint about Haskell records. In this respect this
proposal can be seen as an improvement on what's already been done in
-XDuplicateRecordFields (I don't have much of an experience with
-XDuplicateRecordFields, but I believe it's an improvement); or a way to
use -XNoFieldSelectors without resorting to lenses. To draw a comparison
with Ocaml, again: shared record fields are a reasonably recent feature
there too; it was welcome, but rather as fixing a minor inconvenience
(programmers just namespaced their record fields). Maybe they are more
pressing in Haskell because namespacing is less convenient. I'm not sure
4. is a rather unfortunate behaviour of Haskell's record semantic. It's not
too hard to avoid its pitfalls, so it's ok
5. is more problematic. In fact, before this whole conversation started, if
someone had asked me why people didn't like Haskell records, I would have
told them about partial updates. So this leaves me a bit more dubious
(though I also recognise that it is a hard problem to solve).
6/7. these are broken by this proposal in that the proposal removes syntax
for those. In my very local experience, in record-heavy code, they are
rather uncommon. So those programmers who would really like 2 and 3, are
probably not the same who would be affected by this proposal. But this
carries a risk: we seem to have taken the habit of being suspicious of
fork-like extension. Don't 6 and 7 make this proposal fork-like? (note: 6
can probably be fixed later by adding type parameters to `HasField` (though
the functional dependencies would become more subtle), I'm not sure we have
any plan that would begin to address 7).

I wrote all that, but it hasn't helped me make an opinion. Some people are
very enthusiastic about this proposal, they probably deserve that we
accept. It's definitely not a bad idea. We may want to be worried about the
fork-like aspects; maybe they are not that bad though.

As per syntax, Simon PJ's suggestions, on the github thread, sound pretty
sensible to me. And I'm squarely in team (.foo) (section parentheses for
usage as a function).

Apologies if this message wasn't useful (it probably wasn't). I'll probably
stay a neutral party for the rest of this process.

On Wed, Dec 11, 2019 at 10:11 AM Richard Eisenberg <rae at richarde.dev> wrote:

>
>
> On Dec 11, 2019, at 3:27 AM, Eric Seidel <eric at seidel.io> wrote:
>
> So I think I would be happy with bare `.lbl` being a postfix operator that
> binds less tightly than function application.
>
>
> This means that `f x .bar` is `(f x) .bar` while `f x.bar` is `f (x.bar)`.
> A bit too subtle for me.
>
> Another alternative is to make `.foo` a postfix operator that does not
> associate with function application. That is, `f x .bar` would be a parse
> error. So we can write `x .foo .bar` to mean the same as `x.foo.bar`, but
> we don't have to commit to any strange parsing rules around `f a .b c .d e`.
>
> But I'm starting to lean toward just making bare `.foo` a syntax error and
> revisit this debate with more experience.
>
> Richard
> _______________________________________________
> 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/20191212/4dd7ae61/attachment-0001.html>