SYNTAX ONLY

[fplangc-request@cs.ucl.ac.uk]

From: fplangc-request@cs.ucl.ac.uk
Date: 22 Apr 91 21:24
Sender: Paul Hudak <hudak-paul@cs.yale.edu>
To: fplangc@cs.ucl.ac.uk, kent, guzman-maria@cs.yale.edu
Cc: hudak@cs.yale.edu
Subject: SYNTAX ONLY

Full-Name: Paul Hudak

Dear Syntax Friends:

At the WG2.8 meeting last week there were enough Haskell Committee
members present that we (groan!) held a meeting to try to reach some
decisions about Haskell 1.1.  The most interesting SYNTACTIC issue
discussed was the ambiguity in the precedence of WHERE clauses.  The
unanimous opinion of the Haskell committee members present (me, Simon,
Phil, Arvind, Nikhil, Dick, and Lennart [sitting in for Thomas]) is
that we should use LET instead of WHERE!  This is a VERY RADICAL
PROPOSAL, so we agreed that I should send this message just to the
Haskell committee (plus Kent) first, to get some preliminary feedback
before moving forward.

The advantages of LET over WHERE include:
  - it eliminates the syntactic ambiguitiy problem
    (thus it is safer; fewer divergent missles :-)
  - it binds ids "before their use" just like lambdas, case, and fn defs
    (well, almost; the equations are actually mutually recursive; in any
     case, it is more consistent with the rest of the language)
  - it can't "get lost" off the end of expressions like WHERE clauses can
    (same argument we used to move guards up front)

The disadvantages are:
  - stylistically it is not as "top-down" as WHERE clause
  - it's kind of late to be making such a change!

Overall the advantages were seen to clearly outweigh the disadvantages.

Now, with this decision made, a second EVEN MORE RADICAL proposal was
put forth: eliminate list comprehension syntax in favor of something
that looks like LET!  In particular, instead of, for example:

  [ f x | xs <- xss, length xs > 4, x <- xs ]

one would write:

  for xs <- xss
      length xs > 4
      x  <- xs
  in  f x

The advantages of this proposal include:
  - now ALL binding forms bind their id before use (a Good Thing)
  - the confusing (and arguably broken) notion of scoping
    in list comps is eliminated
  - one can use layout, just as in a LET clause
  - it is "upward compatible" with monad syntax

The disadvantages include:
  - we buck the tradition started by David Turner, thus
    making Haskell more foreign to other fn'al programmers

I would like some feedback on this issue.  A vote along the following
lines is in order:

[1] I vote for using LET and FOR.
[2] I vote for using just LET.
[3] I vote to keep things as they are.

Please cast your vote asap.

  -Paul

-------------

P.S. It is tempting to extend the FOR syntax a wee bit and allow one
to have normal bindings as well.  For example:

  for x <- xs
      y = x+1
  in g y y

but this suffers from the unfortunate property that accidentally
typing two ='s instead of one:

  for x <- xs
      y == x+1
  in g y y

could change the meaning of the expression entirely, yielding yet
another divergent missle! (But note that this property also exists
with the current syntax.)  This can be fixed by, for example,
requiring parens around guards:

  for x <- xs
      (y == x+1)
  in ...

or perhaps making guards look like other guards, as in:

  for x | y==x+1 <- xs
  in ...

etc. etc. However, I'd rather not discuss these alternatives for now.
I mainly want feedback on the main proposal.