Julio Mariņo y Carballo wrote:
> 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 agree that it is a good idea to have some control on whether a
function blocks when applied to some unbound variable or
non-deterministically instantiates its argument. But it still
really don't get your proposal. IIUC, rigidness_projection in the
example above is the name of the library function being used. But
then I don't understand how this would carry over to binary functions,
in particular if both arguments have different types.
Furthermore, if the annotation is attached only to the function
where the rigidness projection is inserted, it still doesn't buy
you much, since you still have to look at the code in order to
see whether it is applied at some point or not. I believe that
in order to make really use of rigidness information, it should
somehow propagate so that I can see with one look at the function
mapIO_ whether it suspends or not when applied to an unbound
variable. Eventually, these annotations should be mixed into the
type system in a way similar to uniqueness annotations in Clean.
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:05 CET