Here are some comments on Sergio's remarks:
> 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.
Would it be useful to post your best example(s) which you think show
narrowing has clear advantages of this kind over rewriting? Michael and I
have played this game several times in the past. It's actually quite
instructive. However, I never felt that Escher showed a clear loss of
expressive power compared with Curry. Indeed, since Escher (in essence)
subsumes Haskell and Haskell is already regarded by some as expressive enough,
I think I am in a good position. So I really would like to see why it makes
sense to go further than Escher. There is clearly a possibility of making
Curry more complicated than necessary, so this point is an important one.
BTW, I don't understand the point about rewriting implying non-determinism.
Please clarify.
> 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.
It sounds like you have in mind providing sets as an ADT. We could do this,
but it misses a lot of possibilities e.g. set abstractions. Many examples
in the Escher paper can't be handled nearly so nicely by an ADT. I would very
much like to see sets provided in a deep and comprehensive way. We have higher
order constructs for this purpose. Let's use them. This creates lots of
implementation challenges, of course, but we are after all supposed to be
pushing the frontiers!
> 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.
Oh, I take it as axiomatic that we want constraints. There are very strong
arguments for this. The problem is how to provide such a facility.
John
>
Received on Mi Jul 02 1997 - 20:03:00 CEST
This archive was generated by hypermail 2.3.0
: Do Jun 20 2024 - 07:15:05 CEST