|Syntax
|~~~~~~
|* Left-hand side syntax. PROPOSED DECISION: go with Kevin's suggestion.
|It is simple, does not require modification if we abandon n+k patterns, and
|nobody has objected to it. Kevin has implemented it, and John Peterson
|(our other implementor) agrees. All agree that the present state is awful.
|PAUL, JOE: do you concur? (Proposed syntax appears at the end of this
|message, for the avoidance of doubt!)
I now concur that something must be done. I tried to argue that from
a programmer's point of view, the state of the current LHS syntax is not
as horridly inconsistent as some have made it out to be, once one
agrees to the principle that an aexp (e.g., a pattern with parentheses
around the outside) on the left always signals a pattern binding.
The more I think about the problem it causes for the parser, though
(non-LR(k) for any k), the more I agree that the problem must be fixed.
I think that Kevin's suggestion is not quite adequate. A couple of
alternatives are proposed at the end of this message.
|
|* Backquotes. DECIDED: leave as in 1.2beta.
|
|* Literate style. DECIDED: PHIL to write an appendix. Preferably to include
|file-naming conventions too.
|
|* Syntax of expressions. Is (case fs of {[f] -> f} x) allowed? PROPOSED
|DECISION (based on my reading of Joe and Paul): no. Meta-rule is that
|expressions extend as far to the right as possible. I'M NOT SURE WHAT
|NEEDS TO BE ALTERED OR UPDATED HERE! Action JOE/KEVIN.
|I *think* all we need is:
| fexp -> exp^{10} aexp
| | aexp
I believe the proposed decision is correct. As to how to implement it,
the above is what we have now. I think all we need is to change it to
the following:
fexp -> fexp aexp
| aexp
|Does anything else need to be added to make precedence of case/lambda more
|explicit?
I don't think so.
|* Associativity of (%), (/)
| Associativity of ::
| JOE TO DECIDE, and tell us
I actually hadn't completely spelled this out. I propose that all the
operators at this precedence level be made left-associative:
infixl 7 /, `div`, `rem`, `mod`, %
OK with everybody?
|
|* Add precedence of @ to the table on page 52. Sounds right to me. ACTION
|Glasgow.
|
|* Should gd -> exp^0 be changed back to gd -> exp? PROVISIONAL DECISON: no.
|We made this choice at Mark Jones' suggestion, to allow us to write
|e::T Int rather than e::(T Int). (I can't remember why this guard stuff
|is a consequence... No action reqd.
|
|Prelude
|~~~~~~~
|* Prelude instances for Text. PROPOSED DECISION: move them to PreludeCore.
|This has the merit that waffle about tuple instances only occurs in Core.
This means exporting a bunch of supporting functions currently not
exported from PreludeText. OK?
|
|* Various minor bugs in the code. ACTION JOE: you know what they are
|because Will has sent them to you.
Right.
|* Ix class. PROPOSED DECISION: Go with the more restrictive version rather
|than permissive version of the constraints in my earlier message (Joe and
|Phil both support this). Any objectors?
Have I missed some mail here? What more permissive version? Are we
talking about defining what index does? I suggested that the proper
constraint is
range (l,u) !! index (l,u) i == i
Is this what you're proposing?
|* Add Enum to superclasses of Real, and Ix to superclasses of Integral
|(Rittri's suggestion). ACTION JOE to decide.
Let's do it.
|* Kent's suggestion to change div and rem. JOE TO DECIDE
Arrgh! Does anyone (besides Kent) have a strong opinion?
|Report presentation
|~~~~~~~~~~~~~~~~~~~
|* Angle brackets vs curlies for exclusion. DECIDED: we do it. Glasgow
|will action.
|
|
|
|
|
|PROPOSED LEFT-HAND-SIDE SYNTAX
|~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| lhs ::= pat{i+1} varop(n,i) pat{i+1}
| | lpat{i} varop(l,i) pat{i+1}
| | pat{i+1} varop(r,i) pat{i}
| | pat
| | var apat+
(Aside: There's a typo in the above that's been copied several times
in succeeding messages: The third production should be
pat{i+1} varop(r,i) rpat{i}
End aside)
This doesn't cover things like
(f .* g) x y = f (g x y)
as every previous version of the syntax has. I don't think we
should backpedal on this one. A modest increase in the complexity
of the proposed syntax allows for this:
lhs ::= (var | @(@ ilhs @)@) apat+
| ilhs
| pat
ilhs ::= pat{i+1} varop(n,i) pat{i+1}
| lpat{i} varop(l,i) pat{i+1}
| pat{i+1} varop(r,i) rpat{i}
I believe this allows for all necessary, but no redundant, parenthesization,
except for redundant parenthesization within patterns.
----------------------------------------------------------------------------
ALTERNATE PROPOSAL
~~~~~~~~~ ~~~~~~~~
Make patterns syntactically a sublanguage of expressions, so that lhs
is just pat . Make an occurrence of a variable where a constructor
is expected or vice versa a semantic error.
----------------------------------------------------------------------------
In either case, we need to decide as well how to resolve the ambiguity
between n+k pattern bindings and definitions of + semantically. Here
are a couple of alternatives:
1) Disallow n+k pattern bindings
2) A binding within an instance declaration cannot be a
pattern binding. Elsewhere, the ambiguity is resolved
as an n+k binding.
--Joe
