Wolfgang Lux wrote:
> [...] First I do not see the reason why you want to restrict the
> expression inside a
>
> let ... free in exp
>
> to the type of constraint.
Neither me.
> [...]
> With your new proposal things get really bad, however, because now
> there is no syntactic distinction between the two cases. E.g. consider:
>
> f x = x <= 2
> g x = x == 1
> h x | f x = 1
> | g x = 2
>
> The result of the reduction h 1 will always be 1. Now if I change the
> definition of g to
> g x = x =:= 1
> (and this might be in a completly different part of the program) I now
> get as result of h 1 the disjunction 1 | 2. (With the old syntax I
> would have got a type error telling me that g x is not of type Bool.)
IMHO, that's not a problem. Another solution would be to change the
typing rule for guards to:
To type
l | g1 = r1
| ...
| gn = rn
type each gi separately, yielding ti. After that, all ti must be
unifiable to either
a) Constraint (default).
b) Bool. In this case, transform the gi = ri to
i) nested ifs (if i>1), or
ii) g1 =:= True = r1 (if i=1)
The report does not state the semantics for the case a) with multiple
guarded rhs yet, but I guess it should be:
l = g1 => r1
l = ...
l = gn => rn
Hmmm, another quite different reading could be
l = choice g1 -> r1
...
gn -> rn
but I didn't think about the consequences of this reading very long...
> So I would suggest either dropping the change in semantics for (only)
> boolean guards in a conditional expression or still use braces around a
> constraint expression the guard of a conditional expression. The latter
> will not conflict with Haskell, as a record can never appear in a guard
> expression.
No! Please nuke the {...} syntax. I've never really understood the
difference between c and {c}, where c::Constraint. I recommend every
language designer to implement the scanner/parser for him-/herself...
> P.S.: Just out of curiosity. What is the reason for replacing /\ by &?
> I've just got accustomed to typing /\ :-)
OK, now from level 0.5 of "WADLER'S LAW OF LANGUAGE DESIGN" back to
level 2... :-)
--
Sven Panne Tel.: +49/89/2178-2235
LMU, Institut fuer Informatik FAX : +49/89/2178-2211
LFE Programmier- und Modellierungssprachen Oettingenstr. 67
mailto:sven.panne_at_informatik.uni-muenchen.de D-80538 Muenchen
nhttp://www.pms.informatik.uni-muenchen.de/mitarbeiter/panne
Received on Fr Okt 23 1998 - 13:09:00 CEST