Michael Hanus wrote:
> Sergio Antoy wrote:
>> I agree with this too. Wouldn't the definition of &> be
>> simpler as follows
>>
>> (&>) :: Success -> a -> a
>> Success &> x = x
>
> This could be the base of the implementation.
Actually, things are not that simple. In the section about the
operational
semantics of Curry, there is footnote 21 (on p. 73 in the latest report)
saying
This means that the evaluation of constraints ... are not shared
since they are not replaced by a value after evaluation but
constraints are solved in order to apply a conditional rule ...
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
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
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.
Regards
Wolfgang
_______________________________________________
curry mailing list
curry_at_lists.RWTH-Aachen.DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/curry
Received on Do Nov 04 2004 - 09:44:46 CET