Wolfgang Jeltsch wrote:
> http://www.haskell.org//pipermail/haskell-prime/2006-January/000077.html has
> interesting thoughts concerning this topic. (The thread started with
> http://www.haskell.org//pipermail/haskell-prime/2006-January/000054.html.)
Thanks for the links. They convince me a bit more that one
should be careful about adding ~-patterns as an alternative
to let...
> > 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 think there were a mail on haskell-prime which pointed out that removal of ~
> patterns may lead to complicated code.
Maybe some special code could be made simpler, but still the question
remains whether this is an advantage compared to the risks.
Note that Curry has a more sophisticated matching strategy
(resulting in optimal evaluations in more situations) compared to
Haskell. This can be easily influenced in a negative way by ~-annotations
(see example above). Thus, I think that this influence should be
made explicit more dominantly, e.g., by an explicit let.
> [...]
> > 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).
>
> I think this is a strong argument for not using _ for anonymous logical
> variables.
>
> > 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".
>
> If it's already forseeable that using _ might be a problem in the future then
> why use it?
Sorry for being imprecise. I think it is not a practical problem
since the variables in function patterns serve two roles-they are
free when evaluating a function pattern to a constructor term
(i.e., a standard pattern) but afterwards they are considered
as pattern variables. Thus, it is not important that one
syntactical construct could denote a free as well as pattern variable
since the difference is not important in that context.
Nevertheless, it could be better to be conservative and wait
a bit for more insights before extending the language of
expressions by "_".
Regards,
Michael
_______________________________________________
curry mailing list
curry_at_lists.RWTH-Aachen.DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/curry
Received on Di Feb 28 2006 - 10:01:09 CET