From: ···@sef-pmax.slisp.cs.cmu.edu
Subject: Re: CMUCL/Dylan, Being pragmatic...
Date:
Message-ID: <CBvtKD.Mos.1@cs.cmu.edu>
From: ···@wstar.mil.wi.us (John P. Flanagan)
... Maybe for a moment in time
we *should* hold CL sacred, at least while the ANSI finish line is in
sight. Let's give CL a fair shake. We're (hopefully) one public review
period away from an official ANSI "CL standard", but here we are chasing
the rabbit (no pun intended) into the next race (Dylan), pondering
failure in a race we haven't finished, let alone lost yet. No one has
said that development of Lisp-like languages must stop because of the
(pending) "standard", but shouldn't we first cross that proverbial
finish line (realize the standard) and thoroughly understand what it
offers (or doesn't offer) before we start running in the next race?
We crossed that finish line six or eight years ago, when Common Lisp was
widely accepted as a de facto standard and the design was frozen (except
for small details and for CLOS, which was added later). Nobody worked
harder to make Common Lisp a usable standard than we at CMU did. The ANSI
standardization, at this point, is not a big event. It just means that the
remaining problems in Common Lisp will never be addressed within the
context of (standard) Common Lisp. Those of us who want to work on some of
those problems should now move on, if we haven't done so already.
We are, after all, a research group. We stayed with Common Lisp this long
because we wanted to work on some compiler and implementation issues, not
because the CL language design is still interesting.
-- 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: ···@wstar.mil.wi.us (John P. Flanagan)
>
> ... Maybe for a moment in time
> we *should* hold CL sacred, at least while the ANSI finish line is in
> sight. Let's give CL a fair shake.
>We crossed that finish line six or eight years ago, when Common Lisp was
>widely accepted as a de facto standard and the design was frozen (except
>for small details and for CLOS, which was added later). Nobody worked
>harder to make Common Lisp a usable standard than we at CMU did. The ANSI
>standardization, at this point, is not a big event. It just means that the
>remaining problems in Common Lisp will never be addressed within the
>context of (standard) Common Lisp. Those of us who want to work on some of
>those problems should now move on, if we haven't done so already.
>We are, after all, a research group. We stayed with Common Lisp this long
>because we wanted to work on some compiler and implementation issues, not
>because the CL language design is still interesting.
I think it's entirely understandable that a research group would
want to move on to new things. I think it's unfortunate that the
language you're moving to is not as freely implementable as Common
Lisp and that it seems to be acompanied by a degree of "Lisp is
bad" attitude. But, in fact, Dylan looks like a fine language
to me, at least so far.
However, your research group could have moved away from CL before
this, and you could have continued to use Common Lisp for research
on programming environments and the like. You could have kept
CMU CL in-house rather than offering it for wider use as an
innovative implementation of Common Lisp (after all you started
on machines like Perqs, which tended to inhibit direct use by
the wider Lisp community). You could have confined your involvement
in CL to language design and avoided partly political issues such
as whether there should be subsets. You could have continued to
make your entire implementation public domain rather than getting
into the business of commercial licenses. And so on.
You have every right to make all of the changes you're making.
However, making this kind of change from CL to Dylan at this
time is bound to have a more profound effect than one might
expect from a mere change in research direction.
-- jd
···@sef-pmax.slisp.cs.cmu.edu writes:
> From: ···@wstar.mil.wi.us (John P. Flanagan)
>
> ... Maybe for a moment in time
> we *should* hold CL sacred, at least while the ANSI finish line is in
> sight. Let's give CL a fair shake. We're (hopefully) one public review
> period away from an official ANSI "CL standard", but here we are chasing
> the rabbit (no pun intended) into the next race (Dylan), pondering
> failure in a race we haven't finished, let alone lost yet. No one has
> said that development of Lisp-like languages must stop because of the
> (pending) "standard", but shouldn't we first cross that proverbial
> finish line (realize the standard) and thoroughly understand what it
> offers (or doesn't offer) before we start running in the next race?
>
>We crossed that finish line six or eight years ago, when Common Lisp was
>widely accepted as a de facto standard and the design was frozen (except
>for small details and for CLOS, which was added later). Nobody worked
>harder to make Common Lisp a usable standard than we at CMU did. The ANSI
>standardization, at this point, is not a big event. It just means that the
>remaining problems in Common Lisp will never be addressed within the
>context of (standard) Common Lisp. Those of us who want to work on some of
>those problems should now move on, if we haven't done so already.
It probably doesn't matter, but we're talking about two different finish
lines here, I was referring to the upcoming ANSI finish line, not that
imaginary point when CL was accepted as the de facto standard in the US
(seven or so years ago). Also, although I know what you meant here by the
term "frozen", from an implementor's perspective, it seems almost comical.
Excluding CLOS, the addition of the Pretty Printer, Logical Pathnames,
and the Loop facility (plus the several hundred changes that have occurred)
are hardly small details.
No one disputes that the CMU group has worked very hard to improve CL,
it's just difficult to understand why some of the remaining problems in
CL can't be addressed in CL. Granted, whatever problems remain will not
be addressed in the context of *this* standard, but they certainly could
could be addressed in the *next-generation* CL standard. I don't
understand why those who want to work on some of these problems should
move on. I browsed your recent posting ("The Igor Project"), but it's
still not clear why the "Igor" environment could not support and be
developed in a *next-generation* CL rather than Dylan. It's too bad a
*next-generation* CL wouldn't work for your project, you wouldn't have
to spend 50% your project building a new language, i.e., Dylan.
BTW, ANSI standardization is probably not a *big* event, but it certainly
will be a significant milestone in the history of CL. ;-)
-- jpf
In article <·····················@wstar.mil.wi.us> ···@wstar.mil.wi.us (John P. Flanagan) writes:
>···@sef-pmax.slisp.cs.cmu.edu writes:
>No one disputes that the CMU group has worked very hard to improve CL,
>it's just difficult to understand why some of the remaining problems in
>CL can't be addressed in CL. Granted, whatever problems remain will not
>be addressed in the context of *this* standard, but they certainly could
>could be addressed in the *next-generation* CL standard. I don't
>understand why those who want to work on some of these problems should
>move on. I browsed your recent posting ("The Igor Project"), but it's
>still not clear why the "Igor" environment could not support and be
>developed in a *next-generation* CL rather than Dylan. It's too bad a
>*next-generation* CL wouldn't work for your project, you wouldn't have
>to spend 50% your project building a new language, i.e., Dylan.
>BTW, ANSI standardization is probably not a *big* event, but it certainly
> will be a significant milestone in the history of CL. ;-)
I feel like a minority here, but I think that the move to Dylan sounds
like a good one. I think that there are interesting aspects to Dylan
that make it (for me) a more attractive alternative to Common Lisp.
Probably the most important of these is size - CL is just _so_big_. Of
course, with the size comes significant power, but I like smaller
languages for their clarity and ease of use. (I feel, like Winnie
ther Poo, that i'm probably "a bear of very little brain").
I also think that the brief teaser about Igor sounds quite interesting
and definitely like something to watch.
--
jefu <=> Jeff Putnam - New Mexico Tech <=> ····@nmt.edu
"Daffodils go Ping! and Oink! // They Really are alarming
I'm scared of big geraniums // And I'm sure that Lilac's harming"
(Dr. Bertram X. Fegg)
····@nmt.edu (Jeff Putnam) writes:
>I feel like a minority here, but I think that the move to Dylan sounds
>like a good one. I think that there are interesting aspects to Dylan
>that make it (for me) a more attractive alternative to Common Lisp.
>Probably the most important of these is size - CL is just _so_big_.
So far as size is concerned, the move could just as well have been
to Scheme. Of course, Dylan may have other advantages, and there's
nothing wrong with hooking up with such developments if they're
suitable.
However, I'd like to keep using Lisp. I don't particularly care
if it's Common Lisp or not (though I'd want a CL-like range of
functionality one way or another). Indeed, Dylan might be
excellent for me if it remains a Lisp and if Apple doesn't
become too aggressive about intellectual property.
Anyway, I did like CMU CL a lot as a Lisp implementation
(not just as a CL), and I'm sorry that it might stop being
supported. It's still possible that someone else will keep
CMU CL going (like U Texas does for AKCL), though, so perhaps
all will be well in the end.
-- jd
····@nmt.edu (Jeff Putnam) writes:
>In article <·····················@wstar.mil.wi.us> ···@wstar.mil.wi.us (John P. Flanagan) writes:
>>···@sef-pmax.slisp.cs.cmu.edu writes:
>>No one disputes that the CMU group has worked very hard to improve CL,
>>it's just difficult to understand why some of the remaining problems in
>>CL can't be addressed in CL. Granted, whatever problems remain will not
>>be addressed in the context of *this* standard, but they certainly could
>>could be addressed in the *next-generation* CL standard. I don't
>>understand why those who want to work on some of these problems should
>>move on. I browsed your recent posting ("The Igor Project"), but it's
>>still not clear why the "Igor" environment could not support and be
>>developed in a *next-generation* CL rather than Dylan. It's too bad a
>>*next-generation* CL wouldn't work for your project, you wouldn't have
>>to spend 50% your project building a new language, i.e., Dylan.
>>BTW, ANSI standardization is probably not a *big* event, but it certainly
>> will be a significant milestone in the history of CL. ;-)
>I feel like a minority here, but I think that the move to Dylan sounds
>like a good one. I think that there are interesting aspects to Dylan
>that make it (for me) a more attractive alternative to Common Lisp.
>Probably the most important of these is size - CL is just _so_big_. Of
>course, with the size comes significant power, but I like smaller
>languages for their clarity and ease of use. (I feel, like Winnie
>ther Poo, that i'm probably "a bear of very little brain").
Yes, CL has a giant toolbox with a somewhat intimidating landscape of
options, but what makes you think that Dylan will remain small?
Its "delivery module(s)" will be small, but Dylan's libraries, drawn in
part from CL code, could become quite large, maybe larger than CL, i.e.,
Dylan could end up offering you more choices than CL does.
>I also think that the brief teaser about Igor sounds quite interesting
>and definitely like something to watch.
True. Facilities like their "hypercode librarian" might someday evolve
into a sophisticated "programmer assistant" which could minimize ASCII
overload and get us a little closer to "intent-directed" programming...
-- jpf.
From: Fernando Mato Mira
Subject: Re: CMUCL/Dylan, Being pragmatic...
Date:
Message-ID: <24tiik$6ol@disuns2.epfl.ch>
In article <·····················@wstar.mil.wi.us>, ···@wstar.mil.wi.us (John P. Flanagan) writes:
> move on. I browsed your recent posting ("The Igor Project"), but it's
> still not clear why the "Igor" environment could not support and be
> developed in a *next-generation* CL rather than Dylan. It's too bad a
> *next-generation* CL wouldn't work for your project, you wouldn't have
> to spend 50% your project building a new language, i.e., Dylan.
How about Igor abstracting out the particular (sorry) dialect, so that you
can use it on/for CL, Dylan or Scheme (a really cool MOP-based compiler is on the way
from the PARC people).
--
Fernando D. Mato Mira
Computer Graphics Lab "There is only one Language
Swiss Federal Institute of Technology and McCarthy is its prophet"
········@di.epfl.ch
FAX : +41 (21) 693 - 5328
Disclaimer:
disclaim([],[]).
disclaim([H|T],[DH,DT]) :- fixed_point_disclaimer(H,DH),
disclaim(T,DT).
fixed_point_disclaimer(Text,fixed_point_disclaimer(Text,_)).
In article <·····················@wstar.mil.wi.us>, ···@wstar.mil.wi.us (John P. Flanagan) writes:
|> No one disputes that the CMU group has worked very hard to improve CL,
|> it's just difficult to understand why some of the remaining problems in
|> CL can't be addressed in CL. Granted, whatever problems remain will not
|> be addressed in the context of *this* standard, but they certainly could
|> could be addressed in the *next-generation* CL standard. I don't
|> understand why those who want to work on some of these problems should
|> move on. I browsed your recent posting ("The Igor Project"), but it's
|> still not clear why the "Igor" environment could not support and be
|> developed in a *next-generation* CL rather than Dylan. It's too bad a
|> *next-generation* CL wouldn't work for your project, you wouldn't have
|> to spend 50% your project building a new language, i.e., Dylan.
|>
|> BTW, ANSI standardization is probably not a *big* event, but it certainly
|> will be a significant milestone in the history of CL. ;-)
|> -- jpf
I agree that a new version of CL can and should be created that addresses
its shortcomings, most notably it's lack of "deliverability".
From my reading of The Igor Project,
I don't see a pressing need for a new language,
but really just a definition of features (or lack of) that will
ensure deliverability.
I would guess that the proposed environment would have lots
of in-depth knowledge of the application program that could go a long way
toward providing the guidance to avoid inefficient code, as well
as global knowledge that could eliminate run-time decisions.
It sounds like a great project no matter what language is used.
Apparently, ARPA feels the need to direct its funds towards commercially-linked
research, and so you can't blame the CMU folks for tweaking their proposal
to that end. This will limit the amount of contribution from
people on the outside, especially since even the CMU work will be licensed, but
perhaps this is a better approach that will produce a more coherent system.
I believe that all the Lisp folks world-wide need to come together to work on
a public-domain system, as I have suggested with a x86-based Lisp Machine.
I've been inspired that it can be done from seeing the development of Linux.
But I'm delighted to see someone, somewhere, doing /something/ that has
a chance of bringing the ideas from Lisp to the larger computing world.
We can all cheer you on and hope it is successful!
-Kelly Murray
In article <·····················@wstar.mil.wi.us> ···@wstar.mil.wi.us (John P. Flanagan) writes:
Excluding CLOS, the addition of the Pretty Printer, Logical Pathnames,
and the Loop facility (plus the several hundred changes that have occurred)
are hardly small details.
Really? I'd say they are. None of them change the fundamental
character of the language, in the way that exceptions do, or in the
way that two big missing pieces, a module facility and a standard
threads interface, would do.
Bill
--
Bill Janssen ·······@parc.xerox.com (415) 812-4763
Xerox Palo Alto Research Center FAX: (415) 812-4777
3333 Coyote Hill Road, Palo Alto, California 94304
In article <·····················@holmes.parc.xerox.com> ·······@parc.xerox.com (Bill Janssen) writes:
>In article <·····················@wstar.mil.wi.us> ···@wstar.mil.wi.us (John P. Flanagan) writes:
>
> Excluding CLOS, the addition of the Pretty Printer, Logical Pathnames,
> and the Loop facility (plus the several hundred changes that have occurred)
> are hardly small details.
>
>Really? I'd say they are.
...speaks here the man who's never had to implement them. Getting all the ANSI
stuff to work, given that much of it is INCOMPATIBLE with CLtL2 and CLtL1, is
a major PITA.
[Mr. Flanagan's original comment was explicitly from the point-of-view of the
implementor]
--
--John
Venue
I OWN the company. Of COURSE they're official opinions!
········@parc.xerox.com (John Sybalsky) writes:
>In article <·····················@holmes.parc.xerox.com> ·······@parc.xerox.com (Bill Janssen) writes:
>>In article <·····················@wstar.mil.wi.us> ···@wstar.mil.wi.us (John P. Flanagan) writes:
>>
>> Excluding CLOS, the addition of the Pretty Printer, Logical Pathnames,
>> and the Loop facility (plus the several hundred changes that have occurred)
>> are hardly small details.
>>
>>Really? I'd say they are.
>...speaks here the man who's never had to implement them. Getting all the ANSI
>stuff to work, given that much of it is INCOMPATIBLE with CLtL2 and CLtL1, is
>a major PITA.
Thanks. I missed Mr. Janssen's posting. I also neglected to add the
Conditions facility to my original list, this might have altered his
response regarding exceptions.
It certainly was (is) a major butt buster getting the ANSI changes to play.
I would also add that for a CL implementor, a round of CL bashing is not
the kind of aspirin I'd prescribe to ease this "major PITA". In any case,
it will be interesting to see how the Dylan story unfolds, especially in
the absence of a formal standards process...
>[Mr. Flanagan's original comment was explicitly from the point-of-view of the
>implementor]
Amen. ;-)
-- jpf.