From: ···@sef1.slisp.cs.cmu.edu
Subject: Re: Future of CMU Common Lisp
Date:
Message-ID: <CB8pr5.5BB.1@cs.cmu.edu>
From: ···@stony-brook.scrc.symbolics.com (Scott McKay)
By the way, Dylan will soon have a primary syntax that doesn't look at all
like Lisp.
And presumably throws the macro baby out with the syntaxtic bathwater.
Pardon my cynicism, but if that's the case, BFD.
Dylan will have macros, well integrated with the new syntax. We won't know
until the final design is available, but I think most old Lispers will find
the new macro design to be acceptable -- maybe even more elegant than nested
backquotes.
-- 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
===========================================================================
Date: Wed, 4 Aug 1993 11:01 EDT
From: ···@sef1.slisp.cs.cmu.edu
From: ···@stony-brook.scrc.symbolics.com (Scott McKay)
By the way, Dylan will soon have a primary syntax that doesn't look at all
like Lisp.
And presumably throws the macro baby out with the syntaxtic bathwater.
Pardon my cynicism, but if that's the case, BFD.
Dylan will have macros, well integrated with the new syntax. We won't know
until the final design is available, but I think most old Lispers will find
the new macro design to be acceptable -- maybe even more elegant than nested
backquotes.
OK. Another thing that deeply troubles me about Dylan is the difficulty
in getting any recent information about. I think that Apple is playing
their cards very poorly in this regard. Rather than including the Lisp
community in the efforts (and yes, I am well aware of the pitfalls of
this), much of the work is proceeding virtually in secret. Given how
much hype there has been about the language, this is really not smart
given how far behind its public schedule Dylan is.
In article <····················@SUMMER.SCRC.Symbolics.COM>, ···@stony-brook.scrc.symbolics.com (Scott McKay) writes:
|> Date: Wed, 4 Aug 1993 11:01 EDT
|> From: ···@sef1.slisp.cs.cmu.edu
|>
|> From: ···@stony-brook.scrc.symbolics.com (Scott McKay)
|>
|> By the way, Dylan will soon have a primary syntax that doesn't look at all
|> like Lisp.
|>
|> And presumably throws the macro baby out with the syntaxtic bathwater.
|> Pardon my cynicism, but if that's the case, BFD.
|>
|> Dylan will have macros, well integrated with the new syntax. We won't know
|> until the final design is available, but I think most old Lispers will find
|> the new macro design to be acceptable -- maybe even more elegant than nested
|> backquotes.
I'd be quite interested to see what they come up with.
I certainly prefer ()'s, but when I used Visual Basic to develop
a PC application, with its gc'ing of strings and an interactive development
environment, I learned to deal with the syntax.
|>
|> OK. Another thing that deeply troubles me about Dylan is the difficulty
|> in getting any recent information about. I think that Apple is playing
|> their cards very poorly in this regard. Rather than including the Lisp
|> community in the efforts (and yes, I am well aware of the pitfalls of
|> this), much of the work is proceeding virtually in secret. Given how
|> much hype there has been about the language, this is really not smart
|> given how far behind its public schedule Dylan is.
This is also one of my reservations about Dylan.
Perhaps once the CMU folks get on board, this will change?
-Kelly Murray
Good afternoon,
I have been following the series of posting on Dylan and the (bleak)
future of CMU CL.
I am not happy about the shutting down of the CMU CL project (call it
whatever you want but that is what looks like). I believe that it is
unfortunate that the group had to rely on Defense money and that, at
the same time, Apple decided that it was not worth to keep on
developing one of the best CL environment around.
After all that is what happened.
CMU did not have any money to spend on something with no market (well,
maybe some) and Apple does not want to market anything that "reminds"
of Lisp.
This has *nothing* to do with the merits of the language and the
surrounding environment.
If it had, everybody would have a Symbolics on her/his desk (that might
have also happened if Symbolics were not as expensive as they were).
If it had, somebody would have already had run an in-depth critics of
Windows NT (which I have not seen anywhere). Dylan seems to me to be a
similar beast.
Enough for griping.
I am still trying to avoid to use C++ for my next project, but I am
not so sure anymore.
I would like to say two things about ensuring some future for CMU CL
and possibly to contribute to have a "comparable replacement".
About CMU CL.
It is my opinion that the most successfull "publicly available"
software is the one release by FSF (i.e. the GNU stuff).
I would suggest the CMU group to consider the possibility (unless they
have some previous restrictions) to give CMU CL to FSF.
About the-future-language-and-environment-which-is-Lisp-but-does-not-want-
to-be-called-like-that (e.g. Dylan)
The comment SWM makes about macros is a very important one.
I believe that there are two main reasons why CL succeds over many
(all) the other languages as a "programmer friendly" language. (Please
note that I know all the arguments against CL).
a) the macro facility and the ability to extend the language in
meaningful ways. Also the consistency of the of the few conventions
about *how* to extend the language help a lot (I am thinking of all
the 'with-*' macros you may find around). I would also put the use
of &key arguments in this category.
b) the availability of a predefined library of data structures (e.g.
hash tables). This is a major hassle in Scheme and in the C++
world. It is enough to remember the story of the stream libraries
by ATT and FSF.
That is to say TNL (the new language) should, IMHO, have (at least)
those two characteristics. The fact that Dylan does not specify I/O is
a major shortcoming.
Well, I think I bored most of the people reading.
Just remember the the most used language in the world is COBOL.
Have a nice day
--
Marco Antoniotti
-------------------------------------------------------------------------------
Robotics Lab | room: 1219 - tel. #: (212) 998 3370
Courant Institute NYU | e-mail: ·······@cs.nyu.edu
...e` la semplicita` che e` difficile a farsi.
...it is simplicity that is difficult to make.
B. Brecht
In comp.lang.lisp Marco Antoniotti <·······@butsomi.cs.nyu.edu> wrote:
>
> It is my opinion that the most successfull "publicly available"
> software is the one release by FSF (i.e. the GNU stuff).
> I would suggest the CMU group to consider the possibility (unless they
> have some previous restrictions) to give CMU CL to FSF.
My understanding is that CMU CL is public domain; that means that nobody
"owns" it (or rather, everyone does). Therefore nobody has to "give" anything
to anyone. The FSF, or anyone else, could adopt it, modify it, and distribute
it to their hearts content.
What they could NOT do is restrict its use. That means that they could not
place it under the CopyLeft, which would restrict your rights to do certain
things with it (like: modify the code and not give away your modifications.)
The FSF has two conflicting goals in situations like this: on the one hand,
they are fundamentally a political organization whose goal is to force
everyone to give away all the software they write. This is why GNU software
is not public domain. On the other hand, they might gain public goodwill by
distributing non-restricted software anyway, even though such software might
fail to prevent others from engaging in the activities they are fighting.
Pieces of CMU CL have made it into every commercial lisp implementation.
This would not have happened if it were CopyLefted instead of public domain.
(But if you want to dispute this, gnu.misc.discuss is the place to do it.)
-- Jamie
In article <················@thalidomide.lucid.com> Jamie Zawinski
<···@lucid.com> writes:
[...]
>My understanding is that CMU CL is public domain; that means that nobody
>"owns" it (or rather, everyone does). Therefore nobody has to "give" anything
>to anyone. The FSF, or anyone else, could adopt it, modify it, and distribute
>it to their hearts content.
>
>What they could NOT do is restrict its use. That means that they could not
>place it under the CopyLeft [...]
I know little of legal matters, but it was my understanding that "Public
Domain" means that you can do *anything* with it, including adopt it into
a proprietary product. So I would have thought the FSF could take a copy
of CMU CL, call it "GNULISP", and place *that* under the CopyLeft. So
anybody who got it from them would be bound by the CopyLeft, but anybody
who got the original CMU CL could do with it as they wished. Is this right?
- Marty
(proclaim '(inline skates))
In article <··········@aplcenmp.apl.jhu.edu> ····@aplcenmp.apl.jhu.edu ([Marty Hall]) writes:
>I know little of legal matters, but it was my understanding that "Public
>Domain" means that you can do *anything* with it, including adopt it into
>a proprietary product. So I would have thought the FSF could take a copy
>of CMU CL, call it "GNULISP", and place *that* under the CopyLeft. So
>anybody who got it from them would be bound by the CopyLeft, but anybody
>who got the original CMU CL could do with it as they wished. Is this right?
Not quite. The FSF could not take CMU CL out of the public domain.
It could, however, create a MODIFIED version which would not be
public domain.
In article <··········@aplcenmp.apl.jhu.edu> ····@aplcenmp.apl.jhu.edu ([Marty Hall]) writes:
>I know little of legal matters, but it was my understanding that "Public
>Domain" means that you can do *anything* with it, including adopt it into
>a proprietary product. So I would have thought the FSF could take a copy
>of CMU CL, call it "GNULISP", and place *that* under the CopyLeft. So
>anybody who got it from them would be bound by the CopyLeft, but anybody
>who got the original CMU CL could do with it as they wished. Is this right?
Not quite. The FSF could not take CMU CL out of the public domain.
It could, however, create a MODIFIED version which would not be
public domain.
Jamie Zawinski <···@lucid.com> writes:
>My understanding is that CMU CL is public domain; that means that nobody
>"owns" it (or rather, everyone does).
>What they could NOT do is restrict its use. That means that they could not
>place it under the CopyLeft, which would restrict your rights to do certain
>things with it (like: modify the code and not give away your modifications.)
They can restrict the use of their version, just as companies who
have based products on some or all of CMU CL have done. Copyleft
aims to prevent people from making a version and restricting access;
public domain does not. That's why FSF doesn't make their work
public domain.
-- jd
I wrote:
> What they could NOT do is restrict its use. That means that they could not
> place it under the CopyLeft, which would restrict your rights to do certain
> things with it (like: modify the code and not give away your modifications.)
J. W. Dalton <····@festival.ed.ac.uk> and about a dozen others wrote:
>
> They can restrict the use of their version, just as companies who have based
> products on some or all of CMU CL have done.
What I said doesn't contradict that. But this hypothetical descendant of
CMU CL on which someone slaps their own copyright is not CMU CL. It is
a derivative work, not the original, which will always be public domain.
(Lucid CL has some CMU CL code in it, and we don't give it away. But
neither do we call our product CMU CL.)
> Copyleft aims to prevent people from making a version and restricting
> access; public domain does not. That's why FSF doesn't make their work
> public domain.
I know all about what CopyLeft is nominally intended to do.
-- Jamie
From: Patrick A. O'Donnell
Subject: Copyright, copyleft, public domain (was Re: Future of CMU Common Lisp)
Date:
Message-ID: <1cuinqpxz@sluggo.ai.mit.edu>
Nothing about copyright is simple -- I urge anyone interested in the
topic to find and read a book on the subject; _The Copyright Book_ is
one (I can get the reference from home if anyone wants it). The statute
itself is illuminating, and can be purchased through your local
government bookstore.
I don't claim to be expert just from reading a couple lay books, but a
couple issues are pretty straightforward:
In article <··········@aplcenmp.apl.jhu.edu>, [Marty Hall] writes:
>
>In article <················@thalidomide.lucid.com> Jamie Zawinski <···@lucid.com> writes:
>[...]
>>My understanding is that CMU CL is public domain; that means that nobody
>>"owns" it (or rather, everyone does).
[...]
>>What they could NOT do is restrict its use. That means that they could not
>>place it under the CopyLeft [...]
>
>I know little of legal matters, but it was my understanding that "Public
>Domain" means that you can do *anything* with it,
_I can do anything, ALMOST_ (Anyone else remember that book?)
> including adopt it into
>a proprietary product.
Yes.
> So I would have thought the FSF could take a copy
>of CMU CL, call it "GNULISP", and place *that* under the CopyLeft.
No. Copyleft involves claiming copyright on the material. One may not
claim copyright on a work one did not originate (unless, of course, the
rights have been transferred to you by one able to do so). One may
copyright significant modifications to the public domain material, but
only those modifications are covered by the copyright.
Just what constitutes an original contribution gets real fuzzy real
fast.
- Pat
From: Dirk Pranke
Subject: Re: Copyright, copyleft, public domain (was Re: Future of CMU Common Lisp)
Date:
Message-ID: <PRANKE.93Aug6131359@Xenon.Stanford.EDU>
In article <·········@sluggo.ai.mit.edu> ···@ai.mit.edu (Patrick A. O'Donnell) writes:
> So I would have thought the FSF could take a copy
>of CMU CL, call it "GNULISP", and place *that* under the CopyLeft.
No. Copyleft involves claiming copyright on the material. One may not
claim copyright on a work one did not originate (unless, of course, the
rights have been transferred to you by one able to do so). One may
copyright significant modifications to the public domain material, but
only those modifications are covered by the copyright.
Just what constitutes an original contribution gets real fuzzy real
fast.
- Pat
Anyway, as is stated in the GNU Public License, the CopyLeft has never
been tested in court, it's more of a "spirit of the law" type thing:
if you use our product, include our source code with your distribution
or we won't play any more reindeer games with you (actually, they'd
probably be a little more irked).
And, what they really want you to do is subsume your product under the
GNU Public License as well (this is why in some circles it's known as
the GNU Public Virus).
I personally don't find the idea of a product going from public domain
("sure, use it, I don't care, send me a postcard or something") to
public virus domain ("it's free and it bloody well better stay free")
all that appealing, especially if the FSF didn't do any of the work
involved.
[NB. I don't have any thing really against the FSF. They make some
great products that I use all the time, and I appreciate it. I also
heartily endorse the idea of public knowledge and public software.
Some of us however occasionally don't have control over how our
programs get shipped out, and furthermore doing something like
packaging the source code can significantly complicate the shipping
process.]
Feel free to send reasonable responses to me ... send flames to
gnu.misc.discuss, as I don't really want to engage in this argument.
--
-- Dirk
(······@cs.stanford.edu)
.-------- ---------.
| "Words exist because of meaning; once you've gotten the meaning, you can |
| forget the words. Where can I find a man who has forgotten words so I can |
| have a word with him?" -- Zhuangzi |
^-------- ---------^
In article <····················@butsomi.cs.nyu.edu>, ·······@butsomi.cs.nyu.edu (Marco Antoniotti) writes:
|>
|> Good afternoon,
|>
|> I have been following the series of posting on Dylan and the (bleak)
|> future of CMU CL.
|>
|> I am not happy about the shutting down of the CMU CL project (call it
|> whatever you want but that is what looks like). I believe that it is
I'm not happy either and I don't even use CMU CL.
|> About CMU CL.
|> It is my opinion that the most successfull "publicly available"
|> software is the one release by FSF (i.e. the GNU stuff).
|> I would suggest the CMU group to consider the possibility (unless they
|> have some previous restrictions) to give CMU CL to FSF.
|>
This is the best suggestion I've heard in a long time. So long as FSF try to make it
comply with the 'standard' then great CMU CL lives.
No doubt the DARPA contract that CMU CL was developed under forbids this sort
of transfer though. Could anyone enlighten the rest of us on this topic ??
Bye,
John
>From: Kelly Murray <···@prl.ufl.edu>
>"Write the OS in Lisp, and they will come"
>From: ···@stony-brook.scrc.symbolics.com (Scott McKay)
>The OS on Lisp Machines is written in Lisp, and nobody came.
>From: ········@kestrel.edu (Jim McDonald)
>So, "Write the *portable*, fast, robust OS in Lisp, and they will come"
Many came to Symbolics, and with big-bucks in hand, but they didn't come back.
(I hesitate to say that people actually ran away from the Perq LispM :-)
Clearly Lisp isn't the only thing you need.
>From: ········@kestrel.edu (Jim McDonald)
>So, "Write the *portable*, fast, robust OS in Lisp, and they will come"
Or make it cheap. You must have one or the other, or in the best case, both.
-Kelly Murray