[ghc-steering-committee] Record syntax

[Simon Peyton Jones]

|  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