Re: Curry mailing list (welcome)

From: Herbert Kuchen <herbert_at_informatik.rwth-aachen.de>
Date: Mon, 16 Dec 1996 13:52:04 +0100

Thanks to Sergio for starting the discussion on the Curry proposal.

Sergio Antoy wrote:
>
> A function has (at least) three pieces of information: type,
> equations, and evaluation annotations. I think that it would
> advantageous to combine them together. This would both keep
> textually close concepts that are conceptually close and make
> certain errors impossible or easier to detect. As an example and
> simplification of what I mean, consider the difference between
> Algol60 and Pascal. In Algol (I quote from memory forgive syntax
> errors) one declares a procedure and its arguments types and modes
> in several steps
>
> procedure p (x, y);
> int x;
> int y;
> value x;
>
> In Pascal (memory again) one compacts all that into
>
> procedure p (value int x, int y);
>
> which is definitely preferable. So the question is "Should we try
> to provide a construct that allows us to define simultaneously
> with the equations also the type and the evaluation annotations
> if they are given?"
>

I think such an integration of the type specification and the equations
is difficult in a functional (logic language), since there usually
several equations. To which equation(s) would you like to add the type
information?
a) To only one of them (e.g. the first one)?
   This seems to be odd, in particular since you do not reach the
   desired integration for all the other equations.
b) To all of them?
   This would introduce a lot of redundancy which would in turn
   endanger consistency. It would have to be checked whether all
   these types are consistent. This does not seem to be a good solution
   either.

On the other hand I am quite happy with the ``functional solution''
to have an (optional) type specification first, followed by the
equations.
Often, in order to get an impression of what a function does, it is
sufficient to look at its name (if this is well-chosen) and its type.
The equations are only considered, if details are important.

> The restriction on the variables in the right hand side of a
> (conditional) equation makes it impossible to define a function f
> such as
>
> f x := y if y = x
>
> which is certainly well-behaved and allowed in many functional
> languages. There is some work by Middeldorp and others that
> relaxes Curry's restrictions and yet guarantees confluence (the
> function is well defined) in situations such as the above example.
> We implemented it in our functional extension of Goedel and it was
> not very hard. So my question is: "Has this issue been studied
> enough or should we study more the issue of the extra variables in
> the right hand side of conditional equations?"

good idea; I agree that this would be interesting

> I would be happy to work out a new proposal of this issue if
> someone sees it fit.

Great

Best,

Herbert
Received on Mo Dez 16 1996 - 14:10:41 CET