Re: prelude extension proposal

From: Wolfgang Lux <>
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.


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

This archive was generated by hypermail 2.3.0 : Fr Okt 07 2022 - 07:15:19 CEST