|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} varop(n,i) pat{i+1}
|> | lpat{i} varop(l,i) pat{i+1}
|> | pat{i+1} varop(r,i) rpat{i}
|
|I don't see any major problem with your proposal once the (n+k)
|ambiguity is resolved. And it is much easier to understand
|than the present syntax.
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 =
but I haven't run anything through a parser generator.
|I could also accept lhs = pat <= exp (now that is simple!). It's
|a bit odd to think of
|
| x * f y = e
|
|as a semantic error, but that's largely a question of error reporting,
|I suppose.
right.
|> 2) A binding within an instance declaration cannot be a
|> pattern binding. Elsewhere, the ambiguity is resolved
|> as an n+k binding.
|
|This seems rather ad-hoc. Why are instance declarations special?
|
| class Integral a => Foo a where
| v :: a
|
| instance Foo Int where
| (v+1) = ...
Quite right. I didn't say this very well. Here's another try:
We _could_ limit the interpretation of of the ambiguity as a binding
of (+) to instance declarations for a class with + in its signature
(usually Num, unless you're using a nonstandard prelude) and interpret
it as an (n+k)-binding anywhere else. However,
|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.
|
|Kevin
I completely agree with this sentiment. I don't know of any programmer
who uses (n+k)-bindings, and at any rate, they are easily replaced by
n | n >= 0 = e - k
I have been bending over backwards to accomodate anyone who thinks we
need to retain these things only because that's what we've been doing
all along. I seem to recall that the original reason was that such
bindings might naturally result from program transformations, but even
if this is the case and the above translation is not acceptable for
some reason, there is also the alternative of using
Lift (n+k) = Lift (e)
where
data Lift a = Lift a
I'm probably preaching to the choir here. Noting that Phil has also
said that banning (n+k)-bindings is acceptable, I suggest we do so.
Cheers,
--Joe
