Re: Proposal for syntax changes in Curry

From: Wolfgang Lux <lux_at_helios.uni-muenster.de>
Date: Fri, 23 Oct 1998 13:18:47 +0100

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

This archive was generated by hypermail 2.3.0 : Do Feb 01 2024 - 07:15:05 CET