Hi Bernd!
> I also think that allValuesOf is much easier to comprehend than the
> findall concept. But there could be an equivalent for allValuesOf in an
> implementation based on weak encapsulation, could there not?
Obviously you can do that. In fact, I've already shown how to do it in
this message:
http://www.informatik.uni-kiel.de/~mh/curry/listarchive/0235.html
In fact, I had to use this trick in order to implement getSearchTree in
the AllSolutions module in MCC.
> [...]
> This section and esp. the contained reference to the denotational
> semantics are indeed incompatible with the intended behaviour of
> allValuesOf. But the Curry-Report does, as far as I know, not state
> much
> about the denotational semantics of encapsulation. It rather talks
> about
> why encapsulation is needed, esp. for use within I/O actions and how
> the
> search operators should behave operationally. Unfortunately, weak
> encapsulation is not much use in ensuring determinism and therefore I
> would prefer in these situations something which can only be defined
> operationally over not being able to do what is needed.
I disagree with your claim that weak encapsulation is of not much use
for ensuring determinism. The point is only that weak encapsulation
makes it impossible to encapsulate non-determinism post facto.
Incidentally,
if Curry were using an eager evaluation strategy, nobody would complain
that it is impossible to write a function like allValuesOf and everybody
would happily be using lambda abstractions (and not partial
applications!)
in order to prevent premature evaluation. The situation is by no means
different when using weak encapsulation in Curry.
Actually, I'm opposed to this allValuesOf function because it blurs an
important distinction, namely that between a variable and a (nullary)
function. Variables (and thus function arguments) are bound to values
and the concept of a non-deterministic value does not make sense to me.
On the other hand, functions represent computations and it makes sense
to have non-deterministic computations.
> The semantical
> problems are the very reason we put getSearchTree in the I/O-Monad.
I can live with that, since this is where encapsulation is most needed.
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 - 15:19:03 CEST