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. The
proposed semantics for constraints leads to the interpretation, that
the function h is deterministic if all its guards of type Bool (even if
the guards are overlapping), but it may introduce non-determinism as
soon I change some guard to a constraint expression.
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.
> 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
At least the appendix about the operational semantics uses this
semantics. IMHO the paragraph in the section about function
declarations also suggests this semantics, but may be it should be
clarified a bit.
> 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...
IMHO, this would make reasoning about the program quite difficult.
Regards
Wolfgang
--
Wolfgang Lux Phone: +49-251-83-38263
Institut fuer Wirtschaftinformatik FAX: +49-251-83-38259
Universitaet Muenster Email: lux_at_helios.uni-muenster.de
Received on Fr Okt 23 1998 - 14:27:00 CEST