Re: Curry design

From: Michael Hanus <hanus_at_I2.Informatik.RWTH-Aachen.DE>
Date: Thu, 3 Jul 1997 13:14:06 +0200

John Lloyd wrote:
> 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.

I am also in a good position since the last sentence is also true
of you replace "Escher" by "Curry" :-)

> So I really would like to see why it makes
> sense to go further than Escher.

I will answer this in a separate message where I discuss the relation
between narrowing and rewriting.

> Which Goffin paper is the best place to look? Two other points: I have already

This should be answered by the authors, but the extended
version which is going to appear in Science of Computer Programming
is a good source.

> built higher-level facilities on top of the concurrent Haskell facilities.
> These are usually what the programmer wants to use. The low-level stuff is
> available if needed. Second, I don't regard delay due to insufficiently
> instantiated redexes as concurrency at all. It just affects the choice of
> redex. The Escher concurrency is big, chunky, coarse-grained, explicit
> concurrency. (I'm trying to get something written on this, so a more
> detailed debate can be had.)

In other words, you do not consider "Concurrent Constraint" languages
like Oz or Goffin as concurrent?

> I'm not sure I understand well yet all the subtleties on this issue. I just
> have the gut feeling that mathematicians and logicians have been solving
> constraint systems for a very long time with the conventional mathematical
> apparatus and therefore there ought to be a way to introduce constraint
> solving in a more seamless way without all the extra Curry stuff. For me,
> adding constraints means smoothly extending the facilities of the computational
> model. It certainly doesn't mean adding a separate constraint solver and a
> lot of extra apparatus and syntax.
>
> In fact, as constraint solving can be very nicely formulated as finding the
> "normal form" of a (complicated) constraint system, Escher already does
> simple constraint solving. To do something more meaningful requires
> manipulating several redexes at the same time. This doesn't require any extra
> syntax - just a clever operational semantics. It's largely transparent to the
> programmer.

Maybe your different understanding is due to the fact that you
are not interested in complete constraint solvers. However,
providing complete constraint solvers requires a different
view of constraints. Thus, the equality symbol is usually interpreted
as strict equality, and also the CLP framework of Jaffar/Lassez
distinguishes between constraints and other user-defined predicates.

Best regards,

Michael
Received on Do Jul 03 1997 - 14:18:00 CEST