Wolfgang Lux wrote:
>
> Sven Panne wrote:
> > [...]
> > IMHO, that's not a problem. Another solution would be to change the
> > typing rule for guards to:
>
> Maybe I have not been clear enough about what my problem is. It is not
> the typing of the guards itself, but the consequence that a little
> change somewhere in the program has the potential of introducing
> non-determinism at a completly different position in the program.
With free variables in guards (or non-deterministicv functions) you get
this non-local behaviour even with the old syntax, e.g.:
foo eval flex
foo 1 = {}
foo 9 = {}
f x | { foo _y } = _y <= 2
g x = x == 1
h x | f x = 1
| g x = 2
I don't think that determinism is a local property.
> [...]
> I'm really worried about the fact the this place where non-determinism
> is introduced is completly unrelated to the position where the change
> in the program was made. The old style of using a different syntax for
> constraints a least would give me an indication where this might happen
> by raising a type error.
But with my typing suggestion, an errot should be raised, too:
f x :: Bool
g x :: Constraint
and Bool is not unifiable with Constraint. It's important to promote
the Bool to Constraint *after* typechecking.
--
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
http://www.pms.informatik.uni-muenchen.de/mitarbeiter/panne
Received on Fr Okt 23 1998 - 15:31:00 CEST