Re: Curry

From: Simon L Peyton Jones <simonpj_at_cse.ogi.edu>
Date: Wed, 18 Dec 1996 09:17:20 -0800

| I wanted to avoid to start with a discussion on the concrete syntax
| because I think this is a minor (of course important) point which
| can be easily changed.

I agree strongly with this, which is why I suggest you use Haskell's syntax.
You can spend a *lot* of time discussing syntax, and modules, as we are
already seeing. The idea of adopting an existing design EVEN IF IT IS NOT
PERFECT is

        * to avoid discussing syntax

        * to take adavantage of an already somewhat tuned design
                (it takes a lot of work to get a design that is
                as good as an existing one)

        * to allow discussion to focus on the concepts.

        * to make the look and feel of the new language be as much
                like an existing one as possible, so as to lure
                new users in.

What you have to give up is the theoretical possibility of doing a better
job for the particular situation you are in.

Michael's other replies illustrate this well. To take just one example.

| > * Why use lower case data constructors? The use of upper and lower
| > case letters in Haskell carries semantic meaning, because
| > constants are written in upper case and variables in lower
| > case. You may think that you want to reserve upper case variables
| > for ex. quant. variables, but you can introduce them by other
| > syntactic means (see Escher, for example).
|
| As we already discussed in Dagstuhl, it is not necessary to use
| uppercase or lowercase characters for constructor or variables,

Nor is it strictly necessary in Haskell. My suggestion is simply: don't
discuss whether it is necessary or not; simply adopt Haskell's convention
unless it is absolutely incompatible with Curry's objectives.

| but the programmer is free to choose what he wants. There are
| also other well-known languages which do not enforce uppercase/lowercase
| rules,

There are indeed. It would also be reasonable to pick one of these other
well-known languages as the base design for Curry.

Let me put it like this: there are two choices:

        1. Whether to use an existing language as a base

        2. If so, whether to use Haskell.

My answer to (1) is a strong "yes". Pick a base langauge, stick to it, and
thereby avoid having many many hours of debate. The only criterion for
using a different syntax or semantics than the base language should be that
it is fundamental to Curry to do so. Michael's point that the semantics of
pattern matching may need to be altered is a case in point.

I also think that the answer to (2) is "yes", but of course I am biased.
It is more important to agree on the answer to (1) first.


I'll shut up now. After all, it's your langauge!

Simon
Received on Mi Dez 18 1996 - 22:10:28 CET