From: ···@sef-pmax.slisp.cs.cmu.edu
Subject: Re: Future of CMU Common Lisp
Date:
Message-ID: <CB9GtE.KDB.1@cs.cmu.edu>
From: ····@festival.ed.ac.uk (J W Dalton)
I'm sorry, but I'm not going to agree that Dylan is not a variety of
Lisp so long it is one.
Well, arguing about arbitrary classifications is a pretty sterile exercise.
I'll just make these points and then you can call Dylan whatever you like.
1. It was a deliberate decision on the part of Apple not to call this new
language "<something> Lisp".
2. The Dylan people at Apple are quite clear that this is first and
foremost to be a language for mainstream programmers and real applications.
If Lisp people also like it for AI and other traditional Lispy
applications, that's great, but that is not the primary goal.
3. It is explicitly not a design goal that existing Lisp programs should
run in Dylan with little or no change. (This was not the case when Common
Lisp was being designed. A lot of ugliness went into CL in the name of
Lisp compatibility, and then we turned around and made a few major changes,
such as lexical scope by default, that blew compatibility away.)
So, in these respects at least, Dylan is not a Lisp dialect. In other
respects, it has a lot in common with Lisp.
-- Scott
===========================================================================
Scott E. Fahlman Internet: ····@cs.cmu.edu
Senior Research Scientist Phone: 412 268-2575
School of Computer Science Fax: 412 681-5739
Carnegie Mellon University Latitude: 40:26:33 N
5000 Forbes Avenue Longitude: 79:56:48 W
Pittsburgh, PA 15213
===========================================================================
···@sef-pmax.slisp.cs.cmu.edu writes:
> From: ····@festival.ed.ac.uk (J W Dalton)
>
> I'm sorry, but I'm not going to agree that Dylan is not a variety of
> Lisp so long it is one.
>Well, arguing about arbitrary classifications is a pretty sterile exercise.
>I'll just make these points and then you can call Dylan whatever you like.
But Scott, I'm not arguing about what it should be called. Call it
"Dylan", that's fine with me. I don't think you have to put "Lisp"
in the name, or even say "Dylan, a variety of Lisp" as one sometimes
sees for Scheme.
But the world is full of languages that resemble Lisp in some ways but
not in others. Dylan's resemblance is closer than that, to the point
that Dylan can be considered a variety of Lisp. The mere fact that
you call it something else doesn't change that, any more than
Lincoln's dog had five legs ("if you call a tail a leg...").
>1. It was a deliberate decision on the part of Apple not to call this new
>language "<something> Lisp".
But that doesn't mean it isn't a Lisp, just that it's not explicit
in the name.
>2. The Dylan people at Apple are quite clear that this is first and
>foremost to be a language for mainstream programmers and real applications.
>If Lisp people also like it for AI and other traditional Lispy
>applications, that's great, but that is not the primary goal.
Do you really think Lisp isn't suitable for anything but AI and
traditional Lispy applications? I don't see any contradiction in
having a Lisp intended for mainstream programmers and real
applications. Indeed, to a large extent, those are goals of
EuLisp.
Scott, I remember you, and CMU folk generally, as defending Common
Lisp. Have you now decided it was all a mistake after all?
>3. It is explicitly not a design goal that existing Lisp programs should
>run in Dylan with little or no change. (This was not the case when Common
>Lisp was being designed. A lot of ugliness went into CL in the name of
>Lisp compatibility, and then we turned around and made a few major changes,
>such as lexical scope by default, that blew compatibility away.)
Sure, Common Lisp wanted backward compatibility, but running existing
programs with little or no change is not a requirement of Lisp in
general.
>So, in these respects at least, Dylan is not a Lisp dialect. In other
>respects, it has a lot in common with Lisp.
At least at present, Dylan is as much a Lisp as various other
languages that people have been perfectly willing to consider Lisp.
It may be wise not to say so in public, but we ought to be
able to say it here, in comp.lang.lisp.
-- jd
I've tried to avoid getting into this pedantic "is it lisp or not" debate, but
In comp.lang.lisp J. W. Dalton <····@festival.ed.ac.uk> wrote:
>
> But Scott, I'm not arguing about what it should be called. Call it
> "Dylan", that's fine with me. I don't think you have to put "Lisp"
> in the name, or even say "Dylan, a variety of Lisp" as one sometimes
> sees for Scheme.
And then wrote:
> At least at present, Dylan is as much a Lisp as various other
> languages that people have been perfectly willing to consider Lisp.
> It may be wise not to say so in public, but we ought to be
> able to say it here, in comp.lang.lisp.
It sure sounds like you're arguing about what it should be called to me.
>> 1. It was a deliberate decision on the part of Apple not to call this new
>> language "<something> Lisp".
>
> But that doesn't mean it isn't a Lisp, just that it's not explicit
> in the name.
These two statements are not incompatible.
>> 2. The Dylan people at Apple are quite clear that this is first and
>> foremost to be a language for mainstream programmers and real applications.
>> If Lisp people also like it for AI and other traditional Lispy
>> applications, that's great, but that is not the primary goal.
>
> Do you really think Lisp isn't suitable for anything but AI and
> traditional Lispy applications?
He didn't say that, and I'm fairly sure he doesn't think it's true.
> I don't see any contradiction in having a Lisp intended for mainstream
> programmers and real applications.
And I doubt any other people reading this group see a *contradiction* there
either. That doesn't make Apple's goals any less sensible. "First and
foremost" does not imply "instead of."
> Scott, I remember you, and CMU folk generally, as defending Common
> Lisp. Have you now decided it was all a mistake after all?
Scott Fahlman, Lisp Basher... He hasn't said anything of the sort! Deciding
that another language has a more promising future than Common Lisp is not the
same thing as deciding that Common Lisp was a mistake.
>> 3. It is explicitly not a design goal that existing Lisp programs should
>> run in Dylan with little or no change. (This was not the case when Common
>> Lisp was being designed.
>
> Sure, Common Lisp wanted backward compatibility, but running existing
> programs with little or no change is not a requirement of Lisp in
> general.
Did anyone say it was?
-- Jamie