El Viernes, 12 de Noviembre de 2004 18:35, Wolfgang Lux escribió:
> 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.
Yes, you are right, unnoticed propagation of rigidness is something you cannot
avoid just by using annotations, you need something else, probably some good
program analysis and also good programming practice. I was just trying to
recall why we had annotations in the first place and trying to recover the
good side of them.
>
> 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).
It seems I did not make this point clear enough -- I am just proposing to
sugar the explicit use of that kind of code. In the new eval declarations
f :: t1 -> t2
f eval rigidness_projection
rigidness_projection is not a new ad-hoc constant but a real Curry function of
type t1 -> t1, probably placed in some standard library module and
implemented via the_primitive_formerly_known_as_rigid. The translation can be
done at the preprocessing stage.
My proposal aims to provide the programmer with good tools to decouple
function and control, with the benefits of factorization control mechanisms,
reducing errors due to improper placement of freezing primitives, etc.
> > 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.
Yes, you are right.
> Regards
> Wolfgang
Best,
Julio
_______________________________________________
curry mailing list
curry_at_lists.RWTH-Aachen.DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/curry
Received on Mo Nov 15 2004 - 10:03:50 CET