Re: Narrowing vs. rewriting
Dear Friends,
After a long silence on this mailing list, the messages are now
piling up too quickly to follow each individual thread. I agree
with John on the importance of practical examples that demonstrate
the various positions made. So, I will start with one.
But before that, there is a remark that I want to comment. John
writes: "Whatever we eventually decide for Curry, we need to be
convinced it is as simple as possible and at the same time is rich
enough to attract programmers!" We cannot realistically expect
simplicity in a language designed by a committee. We will put in
the pet features of each major group working on its development.
Rather than simplicity, we should shoot for restrain, moderation
and an armonious, tasteful way to integrate the way too many
features that Curry will have.
Now the example, a program to compute a permutation of a list.
[] ++ x = x
(x:xs) ++ y = x:xs++y
permute [] = []
permute (x:xs) | u++v == permute xs = u++[x]++v
For those less familiar with this syntax, the last rule is read as
follows: To compute the permutation of a list with head x and tail
xs, first find two lists, u and v, such that the concatenation of
u and v is a permutation of xs, then return the list obtained by
sticking x between u and v.
My final point is about sets. In an earlier message I said that
sets should be available through the language's ADT mechanism.
Perhaps, I was too hasty. The language could be more expressive
and declarative with facilities for set comprehensions, similar to
list comprehensions. I would like to see examples of the
definitions and manipulations of sets that call for more than a
user/library defined ADT.
Regards,
Sergio
Received on Do Jul 03 1997 - 18:13:00 CEST
This archive was generated by hypermail 2.3.0
: Do Jun 20 2024 - 07:15:05 CEST