Michael Hanus wrote:
> I suppose one of the things you like to have included are record
> notation and field labels. After having done some larger software
> projects with Curry with many datatypes with evolving definitions
> over the time, I also think they should be included in the language
> definition. They do not complicate the language considerably
> but are just a useful abbreviation for functions which we
> usually defined by hand when we started these projects.
> So, I intend to include their definition in the report (Bernd
> has already written a proposal for this).
I wasn't thinking of records in particular, but I agree that they
are quite useful and I have missed them a few times. Another
feature I've missed is lazy pattern matching. Incidentally, this is
already implemented in MCC and was (silently) inherited by PAKCS,
so we might as well make this an official part of the language.
> One other mini-proposal: I like to include the definition
>
> x_ = let x free in x
>
> in the prelude. Thus, one can easily introduce free variables
> occurring only once in expressions, e.g., (23,x_,x_).
> This is quite useful in database applications. The name "x_"
> reminds to anonymous pattern variables but is so obscure
> that it might not be in conflict with existing names.
I agree with Wolfgang and Frank that prelude functions should use
names which make their semantics clear. I would have suggested
unknown for this function, but any other name, e.g. free_, would
be okay either.
Yet, your proposal indicates that Curry lacks a convenient way to
introduce anonymous logical variables. Interestingly, Curry had
this ability a while ago, namely before the introduction of free
declarations when a single underscore in an expression denoted a
fresh anonymous logical variable.
The requirement to introduce named logical variables with a
declaration certainly was the right idea, but we may have been
throwing out the baby with the bathwater by removing the ability
to use _ in order to introduce an anonymous logical variable.
Thus, we could define _ as syntactic sugar in expressions for
a call to a prelude function free_ (or whatever it is called),
just like if ... then ... else ... is considered syntactic sugar
for an application of the prelude function if_then_else.
However, introducing _ as a primitive expression in fact would
allow simplifying the language. In particular, we would no longer
need free declarations (thereby giving another keyword back to the
programmer) since the same effect could be achieved with regular
let declarations. E.g., instead of
last xs | ys ++ [y] =:= xs = y where y, ys free
one could write
last xs | _ ++ [y] =:= xs = y where y = _
Using local pattern declarations, one could as well write
last xs | ys ++ [y] =:= xs = y where (y,ys) = _
Regards
Wolfgang
_______________________________________________
curry mailing list
curry_at_lists.RWTH-Aachen.DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/curry
Received on Mo Feb 20 2006 - 17:14:24 CET