Narrowing: yes or no? [was Re: Narrowing vs. rewriting]

From: Manuel Chakravarty <chak_at_greyarea.is.tsukuba.ac.jp>
Date: Fri, 4 Jul 1997 14:59:41 +0900

I changed the subject slightly as, I think, wrt. to the design of
Curry, the question is not whether to use narrowing or rewriting, but
whether to include narrowing or not.


There is no way around rewriting
================================

Apart from the discussion about concurrency, I think there are two
good reasons why important parts of any realistic Curry program will
exclusively use rewriting (not narrowing):

(1) Nobody wants to calculate with Peano numbers.
(2) It will be difficult to find the inversion for most of the
    routines in the X library.

In other words, any realistic programming language has to support the
standard binary representations for integer and floating point numbers
together with the hardware-supplied operations on them.

Furthermore, interfacing to the operating system and standard
libraries is a very important issue that can probably not be achieved
with narrowing. (Of course, you can just add some non-invertible
functions, but than all the nice completeness results are gone.)

Notice that much effort in the FP community was directed towards good
and efficient solutions for the above two points. Implementations care
very much about using unboxed values for binary number representations
to speed up programs, and monads have been proposed as a way to
interface to the operating system and all sorts of external libraries.


Narrowing?
==========

Sure, there are nice examples of programs that given the semantics of
narrowing are short, elegant, and declarative. And I am sure, there
are good applications for narrowing, but I am not sure whether
narrowing is of much use in everyday programming. So, I agree very
much with Phil: without characterizing target applications first, the
whole discussion does not make too much sense.

Furthermore, Sergio's remark may seem cynic, but actually, I think, he
is right:

> 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.

So, what is the purpose of Curry? Initially, I remember, it was meant
to provide a common language for the people working on integration: to
compare implementations, avoid long introduction of syntax in talks,
support cross-fertilization, share code etc. Do we still agree that
this is the purpose of the language?

Manuel
Received on Fr Jul 04 1997 - 09:00:00 CEST