Wolfgang Lux wrote:
> 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.
YES! I did have several of those "eval" functions, too. But apart from
that, I really do think that Wolfgang has made a very good point, and we
should really consider getting rid of eval annotations.
Before coming to the "how" I'd like to contribute a little to the "why".
With eval annotations, certain programs could not be written in curry,
which are nevertheless valid flatcurry programs. For instance
f x y = case x of
A -> fcase y of
...
This mixing of rigid and flexible cases is not possible with normal
programs but are regularly produced by program transformations like
inliners or partial evaluators. Consequence is, that you can not give a
valid representation of their results in Curry.
Another point in favor of making rigidity more explicit:
Consider the function
f eval rigid
f 1 3 = A
f 2 3 = B
and the call f x (x=:=1 &> 3) Provided Michael's proposal about &> was
accepted, there is the question whether this call suspends or not.
Answer: It depends on whether the definitional tree matches left to
right or right to left. However, it makes sense to build the
definitional tree right to left in this case to delay non-determinism as
long as possible (and thus avoid it for some examples). Thus, your
program might work well on a clever implementation of Curry and then,
porting it to another implementation, you get a run-time error
(unsuspected suspension is nothing else).
Any explicit rigidity via case expressions would behave identical for
both implementations.
As to the "how":
> Interestingly, it is very simple to define rigidSpine in Curry
> without any evaluation annotation.
> rigidSpine xs =
> case xs of
> [] -> []
> (x:xs) -> x : rigidSpine xs
> does the job. Eventually, you are unhappy about the fact that
> this relies on case expressions being matched rigidly.
I do not know whther this is a point to be unhappy about. First, the
case corresponds to case in flatcurry with the exception of the
possibility to use _. (And this _ is the main resaon why we cannot
evaluate case flexible. What should we narrow to for
case x of {1 -> 1;_-> 2}?) Thus case was always intended to carry the
information about rigidness or flexibility. We could of course also
consider to introduce fcase e of ... (without allowing _ of course.)
Without wishing to open up an old topic again: What were the reasons to
make seq rigid? Why should it not correspond to head normal form? You
could always define the old seq as
oldseq x y = case x of _ -> y
or does that taste too much like a hack?
Subsuming, I would agree to Wolfgang's proposal to eliminate eval
annotations. I would avoid, however, to introduce a new rigid primitive
and express rigidity by case expressions.
Greetings,
Bernd
_______________________________________________
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:07 CET