Wolfgang Lux wrote:
> This makes me thinking that, the whole approach of evaluation
> annotations is not flexible enough (pun intended). The nice
> point about a HOT (higher-order [polymorphically] typed) language
> is that we really do not need these annotations, but only a few
> primitives. For instance, the only thing that we need in order to
> define a rigid version of map is a simple function
> rigidSpine :: [a] -> [a]
I must admit that I saw the same problems and your solution
is very attractive.
> I propose the addition of a single new primitive function
> rigid :: a -> a
> which is equivalent to the identity function except that it
> suspends until its result is instantiated to a non-variable
> term. [Incidentally, even this function can be defined in
> Curry already:
> rigid x = x `seq` x
> This definitions make use of the fact that seq is rigid in its
> first argument. However, I'm not sure whether making seq rigid
> eventually was another ill-advised suggestion by me.]
Some other people already argued that there is no "natural"
justification that "seq" should suspend on free variables.
With your new proposal, I might be better to have two
primitives "seq" and "rigid" where only "rigid" suspends
and "seq" just computes the head normal form (which could also
be a variable).
> So my conclusion is that we do not need evaluation annotations
> except for committed choice(*), but rather a single new
> primitive function rigid, which allows for a much more flexible
> implementation of communications patterns.
This sounds like a good design which would simplify several issues.
I looked at my programs where I use rigid functions. Almost all
of their uses are related to concurrent programming with ports,
and their rigidity becomes unnnessary if the list of incoming
messages is directly passed through a call to rigidSpine
when the port is opened.
> (*) Probably, one does not need them for committed choice either.
> Looking at the FlatCurry module, I see that PAKCS translates
> functions defined with committed choice into applications of
> the primitive function prelude.commit. So one could get rid
> of evaluation annotations altogether (which has the nice effect
> of giving the keyword eval back to the user -- I did more than
> once define a function eval only in order to be reminded by the
> compiler that this is not an identifier) by making this function
> public.
Same for me. Since committed choice is not implemented in PAKCS
and a general implementation in Curry2Java was a nightmare,
I was also thinking whether it is necessary at all. Ports
provide some form of fair merge (which is some but not the
complete aspect of committed choice). Maybe it is sufficient
to provide a single primitive function
commit :: [(Success,a)] -> a
that takes a list of constraint/expression pairs and returns
one of the expressions whose constraint is satisfied
(without binding variables that are not local to the constraint).
Regards,
Michael
_______________________________________________
curry mailing list
curry_at_lists.RWTH-Aachen.DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/curry
Received on Fr Nov 05 2004 - 11:50:06 CET