Wolfgang Lux wrote:
> Michael Hanus wrote:
> > If you use function patterns, it is not a problem,
> > since the function pattern
> >
> > last (_ ++ [x]) = x
> >
> > is considered as an abbreviation for the infinite set of rules
> >
> > last [x] = x
> > last [_,x] = x
> > last [_,_,x] = x
> > ...
> >
> > i.e., variables in a function pattern are considered as pattern
> > variables which can be bound to partial functions.
>
> I know. However, the FlatCurry translation of last is effectively
> last a1 = let x,xs free in cond (xs ++ x:[] =:<= a1) x
> so I expect the problem to show up for that definition, too.
Right, but the declaration of the pattern variables xs and x
as free variables can be considered as an internal "hack"
to avoid a more complicated extension of the front-end
to include function patterns. The specific status of
the pattern variables is considered in the implementation
of the function pattern unification (=:<=) which might bind
them to unevaluated expressions (which is usually not possible
for logic variables). Thus, I think that possible restrictions
of logic variables w.r.t. partial applications can be implemented
by restricting the implementation of (=:=), (==) (and do not allow
HO patterns).
Best regards,
Michael
_______________________________________________
curry mailing list
curry_at_lists.RWTH-Aachen.DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/curry
Received on Mo Mai 19 2008 - 09:46:15 CEST