[ghc-steering-committee] Record syntax

[Eric Seidel]

I'm happy with either (2) or (3).

But I do wonder how much we should be basing our decision off of the hypothetical method chaining. It looks very compelling, but

  xs .map double
     .filter isEven

will not be valid since lists have no fields, much less functional fields.

People could add virtual fields with custom instances of HasField, but (1) they'd be orphans until we add them to base (which would probably take time) and (2) something about using HasField for this just seems off to me. I can't quite put my finger on it though.. so maybe I'm just being overly conservative.

The important thing for this discussion is that by invoking the method chaining example, we're implicitly endorsing either virtual fields or some other yet-to-be-designed way of treating functions as fields[1]. I think we should be more explicit about that.

Eric

[1] For example, you could imagine functions automatically being virtual fields of their last input type (the last one because we often design functions to be partially applied), but I'm pretty sure that would be awkward in practice.

On Fri, Jan 10, 2020, at 04:41, Simon Marlow wrote:
> My inclination was (3) over (2), because it seems more elegant:
> * it explains the interpretation of "f r.x", as you said, and
> * it means that "f r .x" is not different from "f r.x" (I prefer to 
> avoid whitespace-sensitivity if we can)
> 
> But I'm somewhat persuaded by the "f.map double .filter isEven" 
> example. So there are swings and roundabouts here, I don't see an 
> obvious best choice between (2) and (3).
> 
> Cheers
> Simon
> 
> On Tue, 7 Jan 2020 at 11:29, Simon Peyton Jones via 
> ghc-steering-committee <ghc-steering-committee at haskell.org> wrote:
> > Friends____
> 
> > I’d like to move our record-syntax discussion forward. Link to proposal discussion <https://github.com/ghc-proposals/ghc-proposals/pull/282>, and  December GHC steering committee debates <https://mail.haskell.org/pipermail/ghc-steering-committee/2019-December/thread.html#1387>.____
> 
> > *No-space arguments____*
> 
> > I believe have agreed that ____
> 
> >  f r.x____
> 
> > (with no spaces around the dot, and no parens around r.x) means____
> 
> >  f (r.x)____
> 
> > That is, treat it consistently with qualified names. I asked everyone to express a view; Iavor, Eric, Arnaud, Joachim, and Richard all said it was at least acceptable; others expressed no view. So let’s take that as a decision, at least for now.____
> 
> > *Naked selectors____*
> 
> > Next question: how should we treat a “naked selector”, namely .x where there is no space after the dot, but there is a space before. I think there are three viable choices:____
> 
> >  1. *It’s simply illegal*. This defers the choice; perhaps later we will have more experience to go on.____
> >  2. *It’s a postfix operator*, binding less tightly than function application, but more tightly than any infix operator. So then (r .x) means r.x, and (r .x .y) means r.x.y. But (f r .x) means (f r).x.____
> > This choice naturally supports chaining (nice to have, but not essential). We can write____
> 
> > f .map double____
> 
> >  .filter isEven____
> 
> > meaning *(f.map double).filter isEven*____
> 
> >  1. *It’s a postfix operator*, binding more tightly than function application, just as record update does. So then (f r .x) means (f r.x), and (f r .x .y s .z) means (f r.x.y s.z).____
> > This choice allows us to regard our decision about (f r.x) as what naturally happens if we parse it as three lexemes: f, r, and .x. But it also breaks the “function application binds more tightly than anything else” rule, just as (f r {x=3}) sadly does already.____
> 
> > It does not permit chaining, at least not without stacked-up parens.____
> 
> > In all three cases we allow (.x), meaning (\r. r.x). For (2) and (3) we can regard it as a “section”, like infix operators only simpler because there is no argument.____
> 
> > I think this is the last major question we have to answer.____
> 
> > What are your views? Personally I lean towards (2), but I could certainly live with (1). I’m a bit reluctant to adopt (3).____
> 
> > Simon____
> 
> > __ __
> 
> >  _______________________________________________
> >  ghc-steering-committee mailing list
> > ghc-steering-committee at haskell.org
> > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>