First of all, my apologies for bringing this issue to the list when the
semantic discussion seemed to be over and is the lexical one which is keeping
us busy these days, but I think there were some points missing in the initial
thread.
Wolfgang initial example on declaring spine rigidness actually showed that
current evaluation annotations are lacking in expresiveness and that a
solution based on a simple operator might be used to define a sort of
"rigidness projections" -- like in projection analysis -- which naturally lead
to a code which is both more expressive and also more elegant, as function
and control are decoupled:
rigid_annotated_function = pure_function . rigidness_projection
However, removing annotations just to allow the inlining of some sort of
pseudo-functional freeze-like operator _anywhere_ in your Curry code may not
lead, in general, to a better code and does not serve the original purpose
behind evaluation annotations.
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.)
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 .
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.
Best,
Julio
_______________________________________________
curry mailing list
curry_at_lists.RWTH-Aachen.DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/curry
Received on Fr Nov 12 2004 - 16:23:27 CET