Sven Panne wrote:
>
> Wolfgang Lux wrote:
> > In my example, nothing is non-deterministic in the definition of
> > g x = x =:= 1
> > itself. The whole program becomes non-deterministic however, due to the
> > (IMHO totally unrelated) *change of semantics* in the function h.
>
> My point was only: It's not sufficient to look at the rules of a single
> function alone to conclude if it has a single solution or not. You
> can't do something similar in Prolog, neither. In Mercury the programmer
> has to state such a property explicitly.
I really do not see the problem with the guards. Originally every rule
with more than one guard was nondeterministic, i.e.
f | g1 = r1
| g2 = r2
was always interpreted as
f | g1 = r1
f | g2 = r2
Then was added one very easy rule saying: If all guards of a rule are of type
bool then we translate them into a if-then-else cascade.
With the old Curry syntax it was possible to determine the programmers
intention syntactically, now it is not anymore, we need to do some
typechecking now. Ok, that's a little more work, but it's definitely
a much cleaner way to take the decision based on the types of the guards
instead of relying on the syntactical style.
If someone writes a program like
f x = x <= 2
g x = x =:= 1
h x | f x = 1
| g x = 2
then not all guards are boolean and therefore we get a non-deterministic
reduction of h. Remember that "h x | f x = 1" is just an abbreviation for
"h x | f x =:= True = 1" and the only case where it is not interpretated
that way is with all guards having a boolean type.
Of course, if one first defined g x = x == 1 and then changes the definition
to the one above, the semantics of h change. But of course you cannot
expect to change one function in a program without possibly affecting all
remaining parts that use this function! In that point I agree with Sven.
An even cleaner way would be the one Michael just proposed, i.e. not to allow
the above definition of h due to the mix of boolean and constraint guards.
Thus, Sven's idea
> 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)
would work fine. If the types of ti are not unifiable to either a) or b)
report an error. This might be helpful, because if one mixes guards of
type Bool and Constraint he might have made a programming mistake.
I'm sure Michael will comment that idea further.
Best regards,
Frank
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Dipl.-Inform. Frank Steiner
Lehrstuhl fuer Informatik II
RWTH Aachen, D-52056 Aachen
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Phone: +49 241 80-21241
Fax: +49 241 8888-217
mailto: steiner_at_informatik.rwth-aachen.de
http://www-i2.informatik.rwth-aachen.de/steiner/
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Received on Fr Okt 23 1998 - 17:39:00 CEST