Original-Via: uk.ac.nsf; Thu, 5 Dec 91 16:31:07 GMT
Original-Sender: [EMAIL PROTECTED]
Sorry if you see this twice, but there seem to have been some kind of
delivery problem when I sent it the first time. There has also been
a question added at the end.
1. On p. 24, 125 it says
" type -> type_1 -> type_2
...
Function arrow associate to the right."
Why not be just as explicit for type expressions as for expressions:
type -> btype
| btype -> type
btype -> atype
| tycon atype_1 ... atype_k
(atype as before.)
2. On p. 27, 126 it says
" constr -> type_1 conop type_2"
This would allow e.g. data A = Integer -> Float `OPERA` Bool -> Int.
But I find that confusing, since '->' otherwise seem to have a very low
priority, e.g. in \x -> x `OPERA` y. I suggest you let '->' have the
same low 'priority' in infix constructor declarations, i.e.:
constr -> btype_1 conop btype_2
/kent k
PS
Paul Hudak writes:
> I wonder if the following syntax change is not too late for the
...
...lambda abstraction syntax...
...
> about when we did the fancy re-write of the syntax to accommodate
> explicit precedence levels. Would anyone object seriously to changing
> things back to the way they were?
How do you propose to do that *without* reintroducing ambiguity?
Like this:
exp -> bexp^0 (instead of \ apat...)
| ... (rest as before)
bexp^i -> bexp^i+1 (0<=i<=9)
| exp^i+1 op^(N,i) bexp^i+1
| lexp^i op^(L,i) bexp^i+1
| exp^i+1 op^(R,i) rbexp^i
rbexp^i -> bexp^i+1 (0<=i<=9)
| exp^i+1 op^(R,i) rbexp^i
bexp^6 -> - bexp^7
bexp^10 -> exp^10 bexp^11
| bexp^11
bexp^11 -> \ apat_1 ... apat_n -> exp
(leaving the other productions for expressions unchanged)?
What about if-expressions and let-expressions? Should
those also be in bexp^11?
/kn
