Well, I didn't want to be the first to address this message, since
I am definitely biased toward one of the issues it raises, but
since no one has answered yet, let me start.
First of all, thank you, John, for raising these issues. They
deserve more attention and discussion from our whole community
than they have received so far. I will mostly address narrowing,
which is the only one of the raised subjects that I know a little
about.
> 1. A longstanding difference between Curry and Escher is that the operational
> semantics of Curry is based on narrowing (plus a little more to subsume
> what Escher does), while Escher is based on rewriting. I think there is
> agreement that the Escher model is simpler, but it's been argued that it
> is not sufficiently flexible for various reasons. My experience in
> writing a lot of Escher code is that it is flexible enough as it is. Since
> narrowing and rewriting are the two obvious computational models for a
> declarative language, perhaps some debate on this might somehow clarify
> which is best or at least what the trade-offs are.
I look at it from the following points of view:
1. what/how can we program with narrowing that we could not
without it and what are the trade-offs.
2. what are the advantages of a language based on rewriting
over one based on narrowing.
3. how relevant is this issue among the set of factors that
make (or break) a new language.
Regarding point 1, we can write more elegant and more declarative
programs. These are subjective attributes and the best I can do
is to back up my claim with the many examples, not all of them
convincing, that appear in the literature. A well discussed and
easy to digest example is accessible through my home page. I
think that this example shows that narrowing raises pattern
matching to a level unavailable elsewhere. Recent work seems to
indicate that narrowing per se is not computationally expensive
(in some perhaps rare situations, at least potentially, narrowing
could be more efficent than rewriting). With simple annotations
the programmer can prevent narrowing and rely on rewriting only.
Regarding point 2, simplicity, which is an extremely important
factor in a language, comes immediately to mind. Narrowing is not
easy. On the other hand, rewriting is not as easy as one could
superficially think, since non-determinism is hard to tame. There
are some advantages in dropping narrowing, but not that big, since
narrowing generalizes rewriting. Once you have a good grasp of
rewriting, the gap to understand narrowing is relatively small.
Having a language with narrowing entails a small price for a
programmer who wants to use only narrowing.
Regarding point 3, I have to say that there are other factors that
are as important as, or more than, the operational semantics.
Syntax, for example, to name a sore one. I think that we should
try to write programs that we find elegant and fun, spend an
inordinate amount of time on the syntax, and then pick operational
semantics that fit well this syntax. If you think that this is
silly, think how you choose your last dress, or car, or mate,
whether it was a one-night-stand or your companion for the last 20
years.
> 2. Escher emphasises set processing partly because I think set processing
> facilities have been sadly neglected in language design (usually
> programmers are expected to do everything with lists even when they are
> not at all appropriate) and partly because I use sets to "encapsulate"
> logic programming computations. I would like to see set processing added
> to Curry. What do you think?
Definitely I want set processing --- lists are generally very
cheap abstractions. But I would prefer to see sets in Curry not
as a primitive type, but as a user-defined, perhaps in a core
library, type. Curry should have facilities to define abstract
data types that are good enough to define the kind of set that
most applications need.
> 4. The Curry document introduces the type Constraint and the value Valid.
> I do not understand the need for these. Certainly, one can write
> constraint systems in the usual mathematical way and solve them without the
> need for such things and, logically, Constraint is just Bool. In my view,
> Constraint solving is primarily about building clever constraint solvers -
> it shouldn't have a significant effect on the look or facilities of the
> language. Is the current Curry proposal the best way to handle constraints
> or can we find a way to make constraint solving blend more seamlessly into
> the language?
What is good for narrowing is good for contraints. Do we have
examples of programs that convince us that constraints are worth
to be in the language? Paco & Co. have some very nice examples.
The question is whether there are programming techniques or
approaches that are viable alternatives.
I think that Wirth said that the important thing in designing a
language is what to leave out, not what to put in. We should not
forget the lesson, whether it applies to narrowing, contraints, or
concurrency.
Sergio
--------------------------------
Sergio Antoy
Dept. of Computer Science
Portland State University
P.O.Box 751
Portland, OR 97207
voice +1 (503) 725-3009
fax +1 (503) 725-3211
internet antoy_at_cs.pdx.edu
WWW
http://www.cs.pdx.edu/~antoy
--------------------------------
Received on Mi Jul 02 1997 - 18:17:00 CEST