Wolfgang Lux wrote:
> 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.
Personally, I am not a friend of having various syntactical
constructs for the same thing, and it seems to me that
lazy pattern matching is already covered by let/where expressions.
Moreover, I am not sure whether the semantic consequences of
the little tilde in definitions like
f x ~(False:ys) = if x==0 then ys else []
f x (True:ys) = ys
(note that without the tilde f is inductively sequential, whereas
with the tilde f is overlapping) should be made explicit by
a let declaration as in
f x y = let (False:ys)=y in if x==0 then ys else []
f x (True:ys) = ys
Do you have examples showing that it is worth to hide these consequences
in a tilde annotation instead of a let?
> 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.
I agree that "unknown" is also a good name and I prefer it since
it avoids the strange underscore in a name like "free_".
> 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.
Right. It was omitted due to the complicated definition of finding
the right constraint to which it belongs (at that time logical
variables could only be introduced in constraints).
> 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.
I also thought about this option. However, there is the problem
that an anonymous pattern variable and an anonymous logical variable
have the same symbol. Although this is not a problem in the
current definition of Curry where occurrences of pattern variables
are clearly separated from occurrences of logical variables,
it could become a problem if one allows functional expressions
at pattern positions as in the function pattern proposal (this
has not been sent to this list but you can find a paper on this at
http://www.informatik.uni-kiel.de/~mh/publications/papers/LOPSTR05.html).
Nevertheless, now I think that this is not a real problem
so that it might be worth (for the sake of readability in favor of
"unknown") to allow an expression of the form "_" as an abbreviation
for "unknown" or "let x free in x".
> 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) = _
Although this simplifies the language, introducing several
logical variables as tuples does not look so nice from my
point of view. Morever, omitting free declarations requires
to change a lot of program code :-(
Regards,
Michael
_______________________________________________
curry mailing list
curry_at_lists.RWTH-Aachen.DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/curry
Received on Mo Feb 27 2006 - 14:41:31 CET