Hi Julio!
Nice to be back to the semantic level.
You wrote:
> The idea of evaluation annotations was, in fact, a good one. On one
> hand, the
> use of explicit freeze-like operators was avoided. Secondly, they
> provided
> information about the operational behavior of functions without having
> to
> look into their code. (By the way, a similar argument is behind the
> "block"
> vs. "freeze" issue in Prolog systems.)
But my experience is that they do not work in that way. Because of lazy
evaluation, an argument may be evaluated by a completely different
function
than the one you were looking at. For instance, my problem was an
application
of mapIO_ to an unbound variable. Since this function was (implicitly)
annotated as rigid, I was assuming it would suspend when applied to an
unbound variable. However, this turned out not to be the case and after
quite a while, I finally noticed that mapIO_ is defined as follows
mapIO_ f xs = sequenceIO_ (map f xs)
Only then I recognized that it was the inner map application which
started
instantiating the argument list. So, the rigid annotation does not buy
you anything without looking at the implementation.
In order to get evaluation annotations to work in the intended way, you
have
to combine them at least with demandedness annotations. Incidentally,
the
evaluation annotations present in the early versions of the report did
serve this purpose, but everyone agreed (and rightly so, IMHO) that they
should be replaced by simple eval rigid, eval flex (OK, this is also
already
long gone), and eval choice annotations.
> My proposal would be to keep evaluation annotations, but now with the
> increased expressiveness allowed by rigidness projections, i.e. a
> declaration
>
> f :: [s] -> t
> f eval spineRigid
>
> would transparently load the "eval" library module where only real
> rigidness
> projections occur and replace every use of f by f . spineRigid .
Sorry, but I do not see how this proposal would generalize to user
defined
data types or functions with different argument types. BTW, note that
the
spineRigid function is not a primitive, but has a perfectly valid
definition
in Curry already (see my original posting).
> I also think that actual compilers should also track down any use of
> the rigid
> (or nonVar, or ensure, or whatever) primitive outside the
> eval+projection
> setting.
But this doesn't help at all with respect to case expressions lest you
also
propose to get remove case expressions or make them always perform a
flexible
matching.
Regards
Wolfgang
_______________________________________________
curry mailing list
curry_at_lists.RWTH-Aachen.DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/curry
Received on Mo Nov 15 2004 - 09:55:03 CET