Re: Proposal for syntax changes in Curry

From: Frank Steiner <steiner_at_informatik.rwth-aachen.de>
Date: Fri, 23 Oct 1998 16:35:41 +0200

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 Fri Oct 23 1998 - 17:39:00 CEST

This archive was generated by hypermail 2.3.0 : Fri Sep 20 2019 - 07:15:04 CEST