Re: Proposal: Relaxing restrictions in Curry

From: Michael Hanus <mh_at_informatik.uni-kiel.de>
Date: Thu, 4 Nov 2004 14:06:02 +0100

Wolfgang Lux wrote:
> If we take this strictly, any representation of Success which is
> equivalent to
> data Success = Success
> will not work because sooner or later sharing will occur. This is not

Thanks for this hint, this is a good point.

> really a problem with respect to the language described in the report,
> since the solutions of programs do not depend on how often one repeats
> the evaluation of an equality constraint e1=:=e2 (though the number of
> occurrences of a particular solution could change and thus be observed
> with encapsulated search, but that is a different story). So to share
> or not to share is mainly a question of efficiency in this setup.
>
> However, the situation changes as soon as one uses constraints for other
> purposes. For instance, for PAKCS' port constraints it certainly makes
> a difference whether a constraint
> send msg port
> is shared or not. Without sharing (as intended by the report), the
> evaluation of
> foldr (&) success (take 5 (send "Hello" port))
> will send the string "Hello" five times to the port, whereas with
> sharing
> "Hello" is sent only once to the port (which happens in the PAKCS
> implementation and in MCC as well because both use data Success =
> Success).
> If one represents Success as a data type internally, I don't see how
> sharing could be effectively avoided. IMHO, the only way to avoid

This depends on the implementation. In PAKCS, this is avoided
by a special treatment of "Success" at the point where
sharing is implemented (thanks for the example; when I tried it,
I detected a bug in our current release which I fixed).

> sharing is to define the type Success as
> type Success = ConstraintStore -> ConstraintStore
> i.e., constraints are functions transforming a constraint store into
> another constraint store. The evaluation of a constraint in a guard
> is then invoked by applying this function to the actual store. However,
> this means that the constraint store has to be passed around implicitly
> so that the current store is available at each guard when it is
> evaluated.

I think this is a very good explanation of the Success type.
I always argued that Success is similar to the function type.
It has no constructors but is intended to be applied in conditions,
similarly to functions that are only intended to be applied to
arguments.

Best regards,

Michael
Received on Do Nov 04 2004 - 14:06:02 CET