- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]

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

Date: Fri, 23 Oct 1998 16:35:41 +0200

Sven Panne wrote:

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

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

*
This archive was generated by hypermail 2.3.0
: Di Sep 29 2020 - 07:15:02 CEST
*