Original-Via: uk.ac.nsf; Thu, 5 Dec 91 04:33:50 GMT
Original-Sender: [EMAIL PROTECTED]
| 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:
I agree.
| 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
Yes, indeed. I would think that
Integer -> Float `AIDA` Bool -> Int
should be parsed as
Integer -> (Float `AIDA` Bool) -> Int
and not
(Integer -> Float) `AIDA` (Bool -> Int)
| 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
See my recent message on this subject. Kent's syntax above is similar
to what I'm working on.
--Joe
