[ghc-steering-committee] Record dot notation

Wed Feb 12 20:28:54 UTC 2020

| Since I seem to be of the opinion that this wouldn't be a good inclusion
| while most everyone else is more convinced that *something* along these
| lines is needed or desirable, perhaps someone can explain what sort of code
| they'd like to write which this makes more pleasant in any regard?

Cale, that is a reasonable question, but could you ask it on the GitHub thread, which is read/write to everyone, notably the authors, rather than to the (small) committee?

There are 500+ comments on the proposal thread, at least some of which may help to answer your question.   Looking for DAML repositories on GitHub will also lead you to real code (not just hypothetical) that uses the extension.  

DAML is essentially Haskell + this proposal, so (unusually for a proposal) we do have a substantial code base of existing code that uses the proposal.  Much of it is inside Digital Asset, but some is public.

Digital Asset considered the absence of record selection notation such a severe shortcoming that they would not have used Haskell if Neil had not implemented a fork of GHC that provided it.  Your judgement may differ from theirs, but there is at least one group of production users that was willing to pay a high price to get it.

To me this seems like a high benefit (to some), very low cost proposal.  I suspect (but cannot prove) that this one change will make Haskell more approachable to a large class of users, especially those from an OO background.

Simon

| -----Original Message-----
| From: Cale Gibbard <cgibbard at gmail.com>
| Sent: 11 February 2020 17:29
| To: Simon Peyton Jones <simonpj at microsoft.com>
| Cc: ghc-steering-committee at haskell.org
| Subject: Re: [ghc-steering-committee] Record dot notation
| 
| Since I seem to be of the opinion that this wouldn't be a good inclusion
| while most everyone else is more convinced that *something* along these
| lines is needed or desirable, perhaps someone can explain what sort of code
| they'd like to write which this makes more pleasant in any regard? I've
| seen a lot of negotiation over the potential meaning of frustrating-to-
| visually-parse terms, without much discussion of why terms of those forms
| are desirable in the first place. What messy code are we trying to tidy up
| here?
| 
| I honestly believe that the status quo is preferable to adding more
| overloading of "." -- the main problems with the record syntax from my
| perspective being the fact that it automatically-defines partial functions
| in the case where you have multiple data constructors (crashing is bad),
| and the fact that perhaps incomplete record construction should simply be
| an error rather than a warning, because it's practically never been useful,
| and in the rare cases where one actually might want it, it's not onerous to
| explicitly write an error in.
| 
| Of course, you get no row polymorphism that way, but if we actually want
| row polymorphism, why aren't we considering something like a new kind for
| row variables, and Ermine's row partition constraints? I'm not sure that
| fiddling with this bit of syntax sugar atop algebraic data types and adding
| more sugar on top of it can actually get us to a pleasant/satisfying system
| for row polymorphism.
| 
| Maybe it's bought us the right to use the same record field names in
| multiple places, but not too much else, and any way of doing that will come
| at the cost of being able to figure out what the types of things are by
| looking at the fields which are present, which is an important aspect of
| being able to typecheck code in one's head. If all I get for making it
| harder to mentally typecheck code is the ability to reuse field names, it
| doesn't seem like a very good deal to me. I'd rather continue to
| disambiguate those with prefixes so that when I come across a field
| selection, I can tell the precise type of the record immediately.
| Admittedly, HasField gives you some polymorphism, but without most of the
| usual conveniences of extensible records, and in most real cases, you'd
| want an actual type class anyway, to tell the users of your code that the
| abstraction is not accidental.
| 
| If it bought me substantially more than that, maybe I could be convinced.
| There are some real-world settings where one would plainly want extensible
| records, but they tend to be messy situations where one has somewhat-
| arbitrary combinations of a large number of potential columns. With this
| HasField approach, you still need to explicitly define new data types for
| each combination you want, even if there's a little automatic sugar for
| abstracting over them.
| 
| But even after all that discussion, I don't see why it is that we'd want
| *this* particular syntax for it, which really doesn't look like it fits in
| with the rest of the language very well. Function compositions are common
| and there are a lot of dots in most of the code I've ever worked on already
| -- if not for function composition, then for composition in the
| Control.Category sense. The thought of mixing some partially applied record
| field selectors in there at the same time makes my eyes water (qualified
| names are already kind of annoying). And if this is not about the concrete
| syntax of using dot for yet another thing, then what is it about? We
| presumably already have reasonably convenient ways of expressing everything
| here, don't we?
| 
| I'm baffled.
| 
| On Tue, 11 Feb 2020 at 05:33, Simon Peyton Jones via ghc-steering-committee
| <ghc-steering-committee at haskell.org> wrote:
| >
| > In my message on 7th I said that the first step would be to identify the
| alternatives on which we could subsequently vote.   Since then
| >
| > Joachim suggested (5)
| > I suggested a refinement to that (yesterday), treating r.x as a lexeme
| > like M.x, but otherwise like (5)
| >
| >
| >
| > Does anyone have any other alternatives they actively want to see on the
| list? Then I’ll gather them together and invite you to express your votes.
| >
| >
| >
| > Simon
| >
| >
| >
| > From: Spiwack, Arnaud <arnaud.spiwack at tweag.io>
| > Sent: 11 February 2020 07:59
| > To: Simon Peyton Jones <simonpj at microsoft.com>
| > Cc: ghc-steering-committee at haskell.org
| > Subject: Re: [ghc-steering-committee] Record dot notation
| >
| >
| >
| > I'm swaying back and forth, but I'll go with my gut feeling:
| >
| > 4>3>2>1
| >
| >
| >
| > On Fri, Feb 7, 2020 at 6:13 PM Simon Peyton Jones via ghc-steering-
| committee <ghc-steering-committee at haskell.org> wrote:
| >
| > Colleagues
| >
| > I've been slow on the records front; apologies.
| >
| > I think Joachim is right: we've discussed a lot of options, but in the
| > end much of this is a judgement call with no perfect answers, and it
| > now seems simplest to express our judgement through voting. I think we
| > are all keen to decide this and move on.
| >
| > Proposal:
| > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
| > ub.com%2Fshayne-fletcher-da%2Fghc-proposals%2Fblob%2Frecord-dot-syntax
| > %2Fproposals%2F0000-record-dot-syntax.md&data=02%7C01%7Csimonpj%40
| > microsoft.com%7Ce47e02eaae144bce9ed108d7af17d7c1%7C72f988bf86f141af91a
| > b2d7cd011db47%7C1%7C0%7C637170389249854748&sdata=jMD9cH%2FIhhpA3TT
| > Ik6VCyXuJHUwkyuk%2Bn%2FprxJY5PxQ%3D&reserved=0
| > Lengthy discussion:
| > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
| > ub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F282&data=02%7C01%7
| > Csimonpj%40microsoft.com%7Ce47e02eaae144bce9ed108d7af17d7c1%7C72f988bf
| > 86f141af91ab2d7cd011db47%7C1%7C0%7C637170389249854748&sdata=5MnVKO
| > b85OV4QUi%2F3lVwnZGLv3kgnLr6MV3745PHLiI%3D&reserved=0
| >
| > Here are the alternatives I propose we vote on.  The first order of
| > business is to check that they are all clear; and that I haven't
| > omitted a worthy alternative.  Here they are:
| >
| > 1. Reject the proposal
| >
| > 2. Naked .x is illegal
| >
| > 3. Naked .x is a postfix operator, binding exactly
| >    like application:  f r .x   means (f r).x
| >
| > 4. Naked .x is a postfix operator, binding more tightly
| >    than application: f r .x   means   f (r.x)
| >
| > Under all of (2,3,4) I think we are content that
| >   - (f r.x) means  (f (r.x))
| >   - (.x)    means  (\r -> r.x)
| >
| > By "naked .x" I mean "not preceded by an identifier (e.g. r.x), or an
| > open paren (e.g. (.x)), or a close paren (e.g. (f 3).x)
| >
| > We could re-open more of this, but I'd prefer to keep it to 1-4.
| >
| > Let's just check everyone is happy with these alternatives.  Then we
| > can vote by putting in rank order, and Joachim can run his STV algorithm.
| >
| >
| > I'm the shepherd for this proposal, so let me add my recommendations.
| >
| > I strongly urge that we do not adopt (1); that is, we accept the
| > proposal in some form.  I have been unhappy with GHC's story for
| > records for two decades.  (E.g. Lightweight extensible records for
| > Haskell, Haskell Workshop, Paris 1999.)  But the design space is so
| > complicated that we never found something that felt "obviously right".
| > So we did nothing drastic, and I think that was right.
| >
| > But there was incremental progress, sketched here:
| > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitl
| > ab.haskell.org%2Fghc%2Fghc%2Fwikis%2Frecords%2Foverloaded-record-field
| > s&data=02%7C01%7Csimonpj%40microsoft.com%7Ce47e02eaae144bce9ed108d
| > 7af17d7c1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637170389249854
| > 748&sdata=8Sc4RHcN6qupZPHqgZWlxhBzOZ4Lj4wNIXGHnmdJLTo%3D&reser
| > ved=0
| >
| > * DuplicateRecordFields lets you have multiple records with the
| >   same field name.
| > * The HasField class lets us define overloaded record selection
| >   and update functions.
| >
| > The proposal we are now discussing has no type-system component; it is
| > *only* about syntactic sugar, allowing you to use dot-notation for
| > field selection.
| >
| > Various extensions about syntax for update were discussed, but no
| > longer form part of the proposal; what is left is the core, which has
| > a particularly high benefit/cost ratio.
| >
| > Now, judgements may differ about the importance of syntactic sugar --
| > that's why we have a committee with a diversity of views -- but I
| > believe that dot-notation for record selection is super-important.
| > I've wanted it for ages.  Every other language has it.  We have
| > accepted other syntactic sugar with much lower utility.  And the dot
| > is already a special case, via qualified names.
| >
| > I respect the fact that others may differ, but I really think think
| > this is worth it.  It would be a crying shame to reject this.  Unlike
| > Chris, I don't think anything better is going to emerge, however long
| > we wait.
| >
| > I am more relaxed about 2/3/4.  Personally I hate (4) because I don't
| > like *any* notation in which something binds more tightly than
| > function application.  e.g. I cordially dislike (f K {x=3}) meaning (f
| > (K {x=3})).
| >
| > My preference is for (3), which allows record selection with spaces
| > (which some argue for).  But (2) represents at most a lost
| > opportunity, not a bad thing.
| >
| > Thanks
| >
| > Simon
| >
| > _______________________________________________
| > ghc-steering-committee mailing list
| > ghc-steering-committee at haskell.org
| > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail
| > .haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&a
| > mp;data=02%7C01%7Csimonpj%40microsoft.com%7Ce47e02eaae144bce9ed108d7af
| > 17d7c1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637170389249864744
| > &sdata=5mvKBh3vIWVs9UhZNaQz3x7yQ41saU1r5UQNBIRcUnk%3D&reserved
| > =0
| >
| > _______________________________________________
| > ghc-steering-committee mailing list
| > ghc-steering-committee at haskell.org
| > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail
| > .haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&a
| > mp;data=02%7C01%7Csimonpj%40microsoft.com%7Ce47e02eaae144bce9ed108d7af
| > 17d7c1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637170389249864744
| > &sdata=5mvKBh3vIWVs9UhZNaQz3x7yQ41saU1r5UQNBIRcUnk%3D&reserved
| > =0