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

From: Wolfgang Lux <wlux_at_uni-muenster.de>

Date: Fri, 14 Oct 2005 10:04:53 +0200

Hi Sergio!

*> Perhaps, the same reason could be advocated for the opposite
*

*> decision. Having the function in the prelude with a few lines of
*

*> comments explaining its problems might be better that letting the
*

*> user, particularly if a student, code the function in his program
*

*> and discover the problems the hard way. We, as implementors, look
*

*> much better by making the problems clear rather than sweeping them
*

*> under the rug.
*

It seems like you missed Bernd's point. It is not a question of

sweeping problems under the rug, but a function like allValuesOf

is simply nonsense in an implementation that is based on weak

encapsulation! Just look at Bernd's example again. In MCC, which

uses weak encapsulation, the expression allValuesOf coin

non-deterministically computes the solutions [0] and [1] (not 0 and 1

as Bernd incorrectly wrote). So this function does not compute all

values as its name suggests, but non-deterministically chooses one

of the values. In fact, allValuesOf is equal to \e -> [e] in any

implementation based on weak encapsulation.

IMHO, the whole problem is based on an misunderstanding of the

underlying lazy evaluation semantics of Curry. Note that the

semantics of a call-by-need calculus (i.e. non-strict evaluation

with sharing) in a language with non-determinism is much closer to

a call-by-value calculus than to a call-by-name calculus (i.e.,

non-strict evaluation without sharing). In fact, for expressions

that do not involve bottom, a call-by-need and a call-by-value

calculus will compute exactly the same results. All of this simply

applies to a hypothetical allValuesOf function as well. When this

function is applied to some argument, the value of the argument

is already fixed -- though not yet evaluated -- so there is nothing

to encapsulate or to choose from in the body of the definition of

allValuesOf. And please note that the previous sentence is just

a paraphrase of the description of call-time choice in Sect. 2.3.1

of the Curry report.

Regards

Wolfgang

_______________________________________________

curry mailing list

curry_at_lists.RWTH-Aachen.DE

http://MailMan.RWTH-Aachen.DE/mailman/listinfo/curry

Received on Fr Okt 14 2005 - 10:32:05 CEST

Date: Fri, 14 Oct 2005 10:04:53 +0200

Hi Sergio!

It seems like you missed Bernd's point. It is not a question of

sweeping problems under the rug, but a function like allValuesOf

is simply nonsense in an implementation that is based on weak

encapsulation! Just look at Bernd's example again. In MCC, which

uses weak encapsulation, the expression allValuesOf coin

non-deterministically computes the solutions [0] and [1] (not 0 and 1

as Bernd incorrectly wrote). So this function does not compute all

values as its name suggests, but non-deterministically chooses one

of the values. In fact, allValuesOf is equal to \e -> [e] in any

implementation based on weak encapsulation.

IMHO, the whole problem is based on an misunderstanding of the

underlying lazy evaluation semantics of Curry. Note that the

semantics of a call-by-need calculus (i.e. non-strict evaluation

with sharing) in a language with non-determinism is much closer to

a call-by-value calculus than to a call-by-name calculus (i.e.,

non-strict evaluation without sharing). In fact, for expressions

that do not involve bottom, a call-by-need and a call-by-value

calculus will compute exactly the same results. All of this simply

applies to a hypothetical allValuesOf function as well. When this

function is applied to some argument, the value of the argument

is already fixed -- though not yet evaluated -- so there is nothing

to encapsulate or to choose from in the body of the definition of

allValuesOf. And please note that the previous sentence is just

a paraphrase of the description of call-time choice in Sect. 2.3.1

of the Curry report.

Regards

Wolfgang

_______________________________________________

curry mailing list

curry_at_lists.RWTH-Aachen.DE

http://MailMan.RWTH-Aachen.DE/mailman/listinfo/curry

Received on Fr Okt 14 2005 - 10:32:05 CEST

*
This archive was generated by hypermail 2.3.0
: Sa Jan 25 2020 - 07:15:07 CET
*