Wolfgang Lux wrote:
> Julio Mariņo y Carballo wrote:
>
> > Well, my example tried to be compliant with the familiar form of
> > evaluation
> > annotations, but a more flexible syntax can be considered. An
> > annotation like
> >
> > map f eval spineRigid
> >
> > would desugar every instance of (map f xs) into (map f (spineRigid
> > xs)) and,
> > more generally, annotations of the form
> >
> > f eval rp1 ... rpN
> >
> > would desugar every application (f x1 ... xN) into
> > (f (rp1 x1) ... (rpN xN)).
>
> Well, this looks like a reasonable proposal to me. Yet, the open
> question
> (in order to leave the purely syntactic level :-) is which functions
> qualify as rigidness projections in such a kind of evaluation
> annotations.
> I assume that you do not want to leave this set unrestricted. On the
> other
> hand, I'm not sure whether one can reasonably restrict it to a
> predefined
> set of functions (though at present I would be happy with
> whatever_this_rigid_primitive_is_called_today and the rigidSpine
> function.)
I also think it is problematic to find an appropriate set of
functions. At least, it would increase the complexity of the definition
of the language. On the other hand, with Wolfgang's proposal one could
define the rigidness projections as any other function (and put
some important examples, like ensureSpine, into the prelude)
and write instead of "f eval rp1 ... rpN"
f x1 ... xN = f' (rp1 x1) ... (rpN xN)
where f' is defined like the original f.
I agree with Julio that it is useful to see the possible
rigidness requirements of a function at some place.
However, this need not to be done in the program code.
For instance, the documentation of a function is usually
a good place where this information could be shown.
As a concrete example, look at the documentation of the PAKCS
libraries at
http://www.informatik.uni-kiel.de/~pakcs/lib/.
This documentation is automatically generated, i.e., it is not
a burden to the programmer, and it contains some useful information that
is derived by analysing the program code. For instance, in the
documentation of the concatenation function (++) at
http://www.informatik.uni-kiel.de/~pakcs/lib/CDOC/prelude.html#++
you will find the comment that (++) is "solution complete, i.e.,
able to compute all solutions". In a similar way, one could
also add information about rigidness requirements.
A non-standard type system might be useful to derive such information.
We have used a similar approach to derive non-determinism information,
i.e., we have defined "non-determinism types" for functions.
A similar approach for rigidness is a challenge but might be possible.
Regards,
Michael
_______________________________________________
curry mailing list
curry_at_lists.RWTH-Aachen.DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/curry
Received on Mo Nov 15 2004 - 11:03:13 CET