[ghc-steering-committee] Record syntax
Christopher Allen
cma at bitemyapp.com
Tue Jan 28 18:06:43 UTC 2020
I'd be willing, in some cases, to use things like getField. I have
done so in the past. I have been a happy `lens` user in production
projects.
I don't think the proposal is worth accepting as-is. One of the
reasons I've liked Haskell's design historically is that features were
orthogonal, well-designed, consistent with the rest of the language,
and fairly complete. I do realize that when you're closer to the
sausage-making you're more aware of the flaws. The grade of proposals
some of you are proposing for acceptance into GHC aren't up to the
standards of even languages I wouldn't want to use in my everyday
work.
We can and should set a higher standard than this proposal meets
whether it's been a problem for 10 years or 10 weeks. Anybody that
wants this functionality can have it with the libraries that already
exist. This is how we get another GHC extension that is poorly
understood and doesn't consistently work from one major GHC version to
the next.
I get that it's fun to figure out what kind of syntax would seem the
most sensible or cleanly designed for this feature. What makes this
fun to kick around is the same as what makes it unacceptable for
inclusion in GHC.
None of this is a judgment on the proposal authors themselves. They're
trying to move the ball forward and they put serious effort into the
proposal. I respect that but that doesn't factor into whether it's a
good candidate for inclusion into the compiler. I think perhaps the
design space isn't developed enough right now. I'm hoping we'll have a
compelling solution for this in the future.
On Tue, Jan 28, 2020 at 8:43 AM Cale Gibbard <cgibbard at gmail.com> wrote:
>
> Thinking about it further, I'd often already be somewhat upset with
> overuse of polymorphic getField making it hard to mentally typecheck
> expressions, and hard to ensure that things work as intended.
>
> The meaning of HasField x r a is just that a value of type r has a
> field with the appropriate name x and type a -- it doesn't necessarily
> express that the /meaning/ of that field is what my function expects,
> unless we're globally very careful about our record field names. If on
> the other hand, I ask that people implement an instance of some new
> explicit type class HasMyRelevantQuantity for their types, I am
> provided with some assurance that someone at least thought about what
> the methods of my class were intended to mean, and are not just
> mashing things together which happen to typecheck only because someone
> reused the name of a field that happened to be an Int in both cases.
>
> So I'm already a bit hesitant there. I can imagine it's still very
> convenient in some cases, especially those involving
> automatically-generated types, but usually I'd want people to do
> better about saying what they mean than what HasField gives them.
>
> On Tue, 28 Jan 2020 at 09:29, Simon Peyton Jones <simonpj at microsoft.com> wrote:
> >
> > | I hope we'll get a proposal that doesn't trip into so many gnarly problems
> > | and achieves more of what is expected of a modern record system. It's
> > | worth waiting.
> >
> > That's a legitimate point of view, but we have been waiting -- for *precisely* this reason -- for well over a decade. Personally I think it's time to move.
> >
> > I think voting is fine -- there are matters of judgement here. I'll think about what the questions are.
> >
> > Simon
> >
> > | -----Original Message-----
> > | From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org>
> > | On Behalf Of Christopher Allen
> > | Sent: 28 January 2020 14:18
> > | To: Cale Gibbard <cgibbard at gmail.com>
> > | Cc: ghc-steering-committee at haskell.org
> > | Subject: Re: [ghc-steering-committee] Record syntax
> > |
> > | I'm still where I was before: we should reject this proposal. The
> > | exploding state space of how code using (.) should be parsed and the fact
> > | that there are this many dark corners make this a bad idea. It's not worth
> > | it.
> > |
> > | I hope we'll get a proposal that doesn't trip into so many gnarly problems
> > | and achieves more of what is expected of a modern record system. It's
> > | worth waiting.
> > |
> > | > On Jan 28, 2020, at 08:05, Cale Gibbard <cgibbard at gmail.com> wrote:
> > | >
> > | > Hey guys, I'm new here, what is this weird dot nonsense? :D
> > | >
> > | > Can we perhaps avoid overloading (.) further? Function composition is
> > | > really important, and I was already upset at the lack of visual
> > | > clarity by the time it was used for qualifying modules...
> > | >
> > | >> On Tue, 28 Jan 2020 at 08:58, Eric Seidel <eric at seidel.io> wrote:
> > | >>
> > | >> I agree with Joachim that we should have a formal vote on this point.
> > | It's contentious, as syntax always seems to be, so it would be good to get
> > | everyone's opinion on record, even if that opinion is just "2 and 3 both
> > | seem reasonable to me".
> > | >>
> > | >> But, before we vote, it occurs to me that we have three new committee
> > | members (welcome!) who might have comments or questions. Alejandro, Cale,
> > | and Tom, have you been following the discussion so far, or do you need a
> > | summary? I wouldn't blame you, it's been dragging on for a very long
> > | time..
> > | >>
> > | >>> On Tue, Jan 28, 2020, at 07:12, Joachim Breitner wrote:
> > | >>> I know I know. It matters for what are the names of variables. My
> > | >>> mental parser first looks what are the names (and handles module
> > | >>> prefixes), and then the expression parser runs. At least in my head.
> > | >>>
> > | >>> And module prefixes are not arbitrary expressions (yet…), but the `r`
> > | >>> can be an arbitrary complex expression!
> > | >>>
> > | >>> f (foo bar // baz).r
> > | >>>
> > | >>> vs
> > | >>>
> > | >>> f (foo bar // baz) .r
> > | >>>
> > | >>> would be different under your proposal, but the same under mine.
> > | >>>
> > | >>> But none of this is new to anyone here… why not just vote and get a
> > | decision?
> > | >>>
> > | >>> Cheers,
> > | >>> Joachim
> > | >>>
> > | >>>
> > | >>> Am 28. Januar 2020 12:58:34 MEZ schrieb Simon Peyton Jones
> > | >>> <simonpj at microsoft.com>:
> > | >>>> | With function application, no space or space is irrelevant:
> > | >>>> |
> > | >>>> | f r"" = f r "" ≠ f (r "") = f (r "")
> > | >>>>
> > | >>>> But that is not so
> > | >>>>
> > | >>>> f r x ≠ f rx
> > | >>>> f M.x ≠ f M x
> > | >>>>
> > | >>>> White space (or its absence) matters.
> > | >>>>
> > | >>>> Simon
> > | >>>>
> > | >>>> | -----Original Message-----
> > | >>>> | From: ghc-steering-committee
> > | >>>> <ghc-steering-committee-bounces at haskell.org>
> > | >>>> | On Behalf Of Joachim Breitner
> > | >>>> | Sent: 28 January 2020 11:55
> > | >>>> | To: ghc-steering-committee at haskell.org
> > | >>>> | Subject: Re: [ghc-steering-committee] Record syntax
> > | >>>> |
> > | >>>> | Hi,
> > | >>>> |
> > | >>>> | > Consider (f .x g .y h .z)
> > | >>>> | >
> > | >>>> | > (2) says this means ((((f .x) g) .y) h) .z), so that it
> > | >>>> parenthesises
> > | >>>> | > exactly like function application.
> > | >>>> | >
> > | >>>> | > (3) says it means (((f .x) (g .y)) (h .z)) which, while
> > | >>>> unambiguous,
> > | >>>> | > I dislike cordially.
> > | >>>> | >
> > | >>>> | > I propose to adopt (2).
> > | >>>> |
> > | >>>> | I agree that “exactly like function application” is a great,
> > | simple
> > | >>>> | universal way of explaining the parsing.
> > | >>>> |
> > | >>>> | But I can't stop pointing out that this is inconsistent if we
> > | insist
> > | >>>> | that `f r.x = f (r.x)`.
> > | >>>> |
> > | >>>> | With function application, no space or space is irrelevant:
> > | >>>> |
> > | >>>> | f r"" = f r "" ≠ f (r "") = f (r "")
> > | >>>> |
> > | >>>> | You propose
> > | >>>> |
> > | >>>> | f r.x ≠ f r .x = f (r .x) = f (r .x)
> > | >>>> |
> > | >>>> | while I am still attached to
> > | >>>> |
> > | >>>> | f r.x = f r .x ≠ f (r .x) = f (r .x)
> > | >>>> |
> > | >>>> | I know that this will disappoint a few who want their code to look
> > | >>>> like
> > | >>>> | it does in some other languages (many object oriented langauges,
> > | >>>> | Ocaml), and who do not want to put in the extra parentheses. But
> > | in
> > | >>>> | this case I am leaning towards the elegance of _really_ saying
> > | >>>> “exactly
> > | >>>> | like function application”, not only syntactically, but also
> > | morally
> > | >>>> (a
> > | >>>> | record is a function on a finite set of field names.)
> > | >>>> | I find this very justifiable for a functional programming
> > | language.
> > | >>>> |
> > | >>>> | And I find it very un-haskelly that going from a space to no space
> > | >>>> | between expressions makes a difference (I believe Simon Marlow
> > | >>>> shared
> > | >>>> | this reservation.)
> > | >>>> |
> > | >>>> |
> > | >>>> | If we do insist on “binds more tightly if no space”, then I am
> > | >>>> actually
> > | >>>> | in favor of “also binds more tightly if there is a space”, i.e.
> > | (3)
> > | >>>> | above, to avoid the whitespace-sensitivity.
> > | >>>> |
> > | >>>> |
> > | >>>> | So if it comes to a vote, I think these three options cover all
> > | >>>> | opinions so far?
> > | >>>> |
> > | >>>> | * f r .x = (f r).x; f r.x = f (r.x) -- Simon’s (2)
> > | >>>> | * f r .x = (f r).x; f r.x = (f r).x) -- My take on it
> > | >>>> | * f r .x = f (r.x); f r.x = f (r.x) -- Simon’s (3)
> > | >>>> |
> > | >>>> | Anything else?
> > | >>>> |
> > | >>>> |
> > | >>>> | If we vote, I hope we don't get too many abstinations. Nobody will
> > | >>>> be
> > | >>>> | personally offended if you vote “against” them (I hope), but
> > | >>>> whatever
> > | >>>> | outcome we have better have weight, and is supported by a high
> > | >>>> turnout.
> > | >>>> |
> > | >>>> |
> > | >>>> | And I think we should just vote; we keep rephrasing the same
> > | >>>> arguments
> > | >>>> | with different words.
> > | >>>> |
> > | >>>> | Cheers,
> > | >>>> | Joachim
> > | >>>> |
> > | >>>> | --
> > | >>>> | Joachim Breitner
> > | >>>> | mail at joachim-breitner.de
> > | >>>> |
> > | >>>> |
> > | >>>>
> > | https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joach
> > | >>>> | im-
> > | >>>> |
> > | >>>>
> > | breitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7C99dc94685bb34e
> > | >>>> |
> > | >>>>
> > | 1f694a08d7a3e8faa2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6371580933
> > | >>>> |
> > | >>>>
> > | 72311824&sdata=N7iqz4VoL6oe4ICm3JIVVLW%2BBM%2BVIdGOeYa2obcjqdI%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.has
> > | >>>> | kell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
> > | >>>> |
> > | >>>>
> > | committee&data=02%7C01%7Csimonpj%40microsoft.com%7C99dc94685bb34e1f694
> > | >>>> |
> > | >>>>
> > | a08d7a3e8faa2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637158093372311
> > | >>>> |
> > | >>>>
> > | 824&sdata=AnxNHulQCUqWkKaKYmEXYQMQwl3F1MDPYS64GIAnVhA%3D&reserved=
> > | >>>> | 0
> > | >>> _______________________________________________
> > | >>> 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
> > | > _______________________________________________
> > | > 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
--
Chris Allen
Currently working on http://haskellbook.com
More information about the ghc-steering-committee
mailing list