Original-Via: uk.ac.ox.prg; Fri, 1 Nov 91 18:04:12 GMT
Brian Boutel writes:
| With Haskell as it is currently defined, one can take an operational view,
| that the syntactic translation given in the report defines the semantics
| of n+k patterns, and too bad if the semantics of the introduced f
Original-Via: uk.ac.ed.mrcvax; Fri, 1 Nov 91 14:00:30 GMT
> | Which leads me to one final comment. Does the Report say anywhere that
> | an overflow gives rise to an undefined result?
>
> Yes it does (though you may not like the answer!). See Section 6.8.1, p56.
>
> Simon
X-Comment1: #
X-Comment2: # uk.ac.glasgow.cs has changed to uk.ac.glasgow.dcs #
X-Comment3: # If this address does not work please ask your mail#
X-Comment4: # administrator to update your NRS & mailer tables. #
X-
Original-Via: uk.ac.st-and.cs; Fri, 1 Nov 91 09:49:13 GMT
It has been pointed out to me by the Yale implementers
that the expression a*b/c causes a parse error because / is infix
rather than infixl and is of the same precedence (7) as * which IS
infixl.
Is this an oversight of someone on the com
Original-Via: uk.ac.ed.mrcvax; Fri, 1 Nov 91 10:03:45 GMT
| Which leads me to one final comment. Does the Report say anywhere that
| an overflow gives rise to an undefined result?
|
| Tony
Good question! I think it should, though I fear the efficiency implications.
Ian
Original-Via: uk.ac.st-and.cs; Fri, 1 Nov 91 09:37:40 GMT
Brian says there are two distinct problems with n+k patterns,
1) That laws relating * `div` `rem` + - might not hold.
2) A user defined >= might not be strict giving rise to a match
of bottom to a refutable patt
Original-Via: uk.ac.nsf; Fri, 1 Nov 91 01:19:12 GMT
Simon says:
This is certainly technically feasible. As it happens, our compiler is set
up so that it is easy to compile any pattern which you can express as a
predicate function ("does it match?") plus an extract-binder
