Re: Proposal: Relaxing restrictions in Curry

From: Wolfgang Lux <wlux_at_uni-muenster.de>
Date: Thu, 4 Nov 2004 17:21:23 +0100

Michael Hanus wrote:
>> 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).

Ok. I keep forgetting that your implementation performs a (runtime)
sharing analysis.

>
>> 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.

I was assuming that because you once remarked that you like to consider
success as being a base operation similar to return () in the IO monad.
I have to admit that Success = ConstraintStore -> ConstraintStore is not
really a practical definition -- at least as long as you want to
consider
ConstraintStore as a set of constraints. The only sensible
interpretation
of ConstraintStore would be as a (mutable) reference to the current set
of constraints. Since all constraints should be using the same
constraint
store, they must return the same constraint store reference that was
passed
as input to them, so one could as well use Success = ConstraintStore ->
().

BTW, an interesting side effect of this change of representation is that
the constraint (x =:= 1) =:= (x =/= 2) (MCC uses the operator (=/=) for
disequality constraints), will now fail even though both constraints are
satisfied.

Regards
Wolfgang
Received on Fr Nov 05 2004 - 09:06:59 CET