> Good. Let me add a disclaimer, though. This appears to me still to be
> LR-parseable (except for the genuine ambiguity), because in the absence of
> arbitrary parenthesization, a finite lookahead is sufficient to distinguish,
> for example,
>
> (n+1) x =
> from
> (n+1) `op` x =
>
>
|Joe writes:
|> [My simple syntax for LHSes] doesn't cover things like
|>
|> (f .* g) x y = f (g x y)
|
|and proposes a syntax which is the same as my simple proposal,
|but covers exactly this also.
|
|> lhs ::= (var | @(@ ilhs @)@) apat+
|> | ilhs
|> | pat
|>
|> ilhs ::= pat{i+1} varo
> Let's either disallow (n+k) pattern bindings or always resolve the
> ambiguity as an (n+k) pattern. I'd prefer the former, but I never
> use (n+k) patterns, anyway.
Likewise!
> Kevin
Ian
Joe writes:
> [My simple syntax for LHSes] doesn't cover things like
>
> (f .* g) x y = f (g x y)
and proposes a syntax which is the same as my simple proposal,
but covers exactly this also.
> lhs ::= (var | @(@ ilhs @)@) apat+
> | ilhs
> | pat
>
>
|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 prese
> * 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.
I agree, if we don't do this, then
