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

From: Wolfgang Lux <lux_at_wi.uni-muenster.de>

Date: Tue, 15 Jan 2002 11:13:42 +0100

Michael Hanus wrote

*> If this is the case (and it actually seems to be the case),
*

*> one has to decide what is more important: sharing or encapsulation?
*

*> As Frank already pointed out, there must be a possibility to
*

*> encapsulate all non-determinism in order to write reliable
*

*> interactive programs. Thus, if my option 3 is the only possibility
*

*> to do this, I am still in favor to commit to it, even we loose
*

*> sharing or, as you pointed out, the results depend on the evaluation
*

*> order. Note that this is in some sense already be the case:
*

*> if you change the order of defining equations (which does not change
*

*> the declarative meaning of a function), you obtain the answers
*

*> in a findall in a different order. This is due to the fact that
*

*> "try" is a meta-level construct which depend on the evaluation order
*

*> of the underlying program.
*

This is true. And in fact the situation is even worse. You cannot even

rely on findall returning the solutions of the simple goal

findall (\x -> x=:=coin)

in the textual order of the definition of coin, i.e. [0,1]. An implementation

might choose to return the solutions in any order it finds suitable (though

probably all existing implementations return the solutions in their textual

order).

But IMHO this is still something different than returning completly different

solutions depending on the order of evaluation. And I cannot imagine how to

write "reliable" programs, if the insertion of a flip operation (e.g. using --

probably indirectly -- flip (==) instead of (==) to compare two values) will

not only change the order of results but also whether some results are

produced at all.

*> It is unclear to me what do you mean by "sound"?
*

*> "Try" is related to the meta-level, so it might be difficult to
*

*> talk about soundness for "try".
*

By unsound in this case I mean that y /= y can be true under option 3. I find

this unacceptable even for a meta-level construct in the language. Therefore

IMHO option 3 is not an option.

Regards

Wolfgang

Date: Tue, 15 Jan 2002 11:13:42 +0100

Michael Hanus wrote

This is true. And in fact the situation is even worse. You cannot even

rely on findall returning the solutions of the simple goal

findall (\x -> x=:=coin)

in the textual order of the definition of coin, i.e. [0,1]. An implementation

might choose to return the solutions in any order it finds suitable (though

probably all existing implementations return the solutions in their textual

order).

But IMHO this is still something different than returning completly different

solutions depending on the order of evaluation. And I cannot imagine how to

write "reliable" programs, if the insertion of a flip operation (e.g. using --

probably indirectly -- flip (==) instead of (==) to compare two values) will

not only change the order of results but also whether some results are

produced at all.

By unsound in this case I mean that y /= y can be true under option 3. I find

this unacceptable even for a meta-level construct in the language. Therefore

IMHO option 3 is not an option.

Regards

Wolfgang

-- Wolfgang Lux Phone: +49-251-83-38263 Institut fuer Wirtschaftinformatik FAX: +49-251-83-38259 Universitaet Muenster Email: wlux_at_uni-muenster.deReceived on Mi Jan 16 2002 - 02:10:46 CET

*
This archive was generated by hypermail 2.3.0
: Do Mai 23 2024 - 07:15:06 CEST
*