Re: Evaluation Annotations: are they needed?

From: Wolfgang Lux <>
Date: Fri, 12 Nov 2004 18:35:02 +0100

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
than the one you were looking at. For instance, my problem was an
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
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
to combine them at least with demandedness annotations. Incidentally,
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
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
data types or functions with different argument types. BTW, note that
spineRigid function is not a primitive, but has a perfectly valid
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
propose to get remove case expressions or make them always perform a


curry mailing list
Received on Mo Nov 15 2004 - 09:55:03 CET

This archive was generated by hypermail 2.3.0 : So Dez 03 2023 - 07:15:08 CET