Lisp per se
Erik Naggum
[discussion limited to comp.lang.lisp.]
* Paul Wilson in <5ja35t$n...@roar.cs.utexas.edu>
| (And by the way, generic functions are not part of Lisp per se, they're
| part of Common Lisp with CLOS and some other languages that adopted the
| idea, including some OOP languages.)
I have seen this argument a few times around, which I take to mean that
there is some ideal notion of "Lisp" that refuses manifestation in the real
world. while one can easily that Common Lisp the Standard (ANSI X3.226) is
not "Lisp per se", but equally easily iterate through all specifications
and implementations with the identical outcome, one has to ask: what _is_
this "Lisp per se" that it is useful to talk about?
one problem with this "Lisp per se" concept (if it be valid) is that it is
very easy for someone to argue against something in some Lisp that "ah, but
that's not Lisp _per se_". take lexical scope. some diehard critics still
believe that "Lisp per se" has dynamic scope and claim that arguments to
the effect that almost all Lisp implementations use lexical scope by
default are irrelevant.
to me, "Lisp per se" appears as a gateway for just such invalid arguments.
perhaps this "Lisp per se" is also the Lisp "idea" that people object to.
now, if "Lisp" means "dynamic scope", I would have serious trouble arguing
for its use myself, and I would understand those who argue against Lisp if
this is their argument. indeed, I have often had to convince people that
the version of Lisp described in their textbooks is as outdated as if their
electronics textbooks would not even discuss transistors. I wonder why
people don't think they need to know what "Lisp" is _today_, and I think
maybe this "Lisp per se" argument is the cause of that unwillingness.
can we help the Lisp image by upgrading the "Lisp per se" idea? how many
serious players would we offend by equating "Lisp" with ANSI Common Lisp?
#\Erik
--
I'm no longer young enough to know everything.
Marc Wachowitz
Erik Naggum (er...@naggum.no) wrote:
> * Paul Wilson in <5ja35t$n...@roar.cs.utexas.edu>
> | (And by the way, generic functions are not part of Lisp per se, they're
> | part of Common Lisp with CLOS and some other languages that adopted the
> | idea, including some OOP languages.)
> I have seen this argument a few times around, which I take to mean that
> there is some ideal notion of "Lisp" that refuses manifestation in the real
> world.
The general term "Lisp" is fuzzy, referring to a large (and evolving)
family of languages and implementations, and a related culture of
programming. While there will be some boundary cases, many people who've
got a reasonable understanding of the problems and solutions which have
appeared in that context are probably able (not necessarily willing ;-)
to recognize some characteristic similarities e.g. among Common Lisp,
EuLisp, R4R-Scheme, Standard Lisp, Oaklisp, T, Emacs Lisp, Lisp 1.5,
and their shared contrast to ML, C, Haskell, Prolog, Modula-3, Ada,
Eiffel, Fortran and Cobol. This shared similarity and contrast might
not be sufficiently precise to unambiguously define the term "Lisp
per se", but it does still convey something meaningful, as far as I'm
concerned. Whether some particular approach or feature is included by
the expression "Lisp per se" will, of course, depend on the context
where it's used, and whether the emphasis is e.g. on the history of
programming (like macros with s-expressions for program manipulation)
or an advanced view on some design question (like hygienic macros as
developed in the context of Scheme). Adding "per se" to the general
term "Lisp" would seem to emphasize the characteristic commonality,
rather than merely including everything falling into the broad "Lisp"
category.
(Btw, I don't have the impression that Paul Wilson's usage of the term
is promoting some concrete image of "Lisp per se", blaming existing
manifestations for not meeting the ideal. From what I've read on various
newsgroups, mailing lists and other texts, I doubt you'd be able to find
many traces of the now popular language fanaticism in his views. What
you may find are reflections about programming, both on the understanding
of existing practice and on advancing the state of the art.)
> can we help the Lisp image by upgrading the "Lisp per se" idea? how many
> serious players would we offend by equating "Lisp" with ANSI Common Lisp?
I wouldn't consider that a question of offense (and that by itself
wouldn't necessarily stop me from using such an equation ;-), but a
question of usefulness for communication among people. Sometimes it
may be clear from context that "Lisp" refers to Common Lisp (with or
without some extensions to what's standardized by ANSI), in other
contexts, I think the generalization over a larger family of languages
and implementations and a programming culture is worth keeping around.
Then more specific references should explicitly talk of Common Lisp,
EuLisp, Scheme, or whatever the relevant dialect happens to be. Common Lisp
may be dominant in some areas - and among the _available_ alternatives,
it's probably the best choice in many cases - but that doesn't make the
cases where Common Lisp isn't used less serious, and IMO it would be a
bad idea to "deny one's relatives" merely because they aren't mainstream.
Erik, you've got Richard P. Gabriel's paper on your home page, where he
remarks that there's a short term need, which is Common Lisp, and a long
term need, which implies moving beyond Common Lisp - which I understand
to mean more than adding some qualities to Common Lisp. I wonder whether
you share the second evaluation, and if that is so, whether you've given
some thoughts to the directions towards "Lisp - The Next Generation".
(Sorry if some people might take this as yet another attempt to damage
Common Lisp; that's neither the intention nor a necessary consequence of
reflections about this topic.)
-- Marc Wachowitz <m...@ipx2.rz.uni-mannheim.de>
Kelly Murray
In article <5jb8d8$17e$1...@trumpet.uni-mannheim.de>, m...@ipx2.rz.uni-mannheim.de (Marc Wachowitz) writes:
>> Erik Naggum (er...@naggum.no) wrote:
>> > * Paul Wilson in <5ja35t$n...@roar.cs.utexas.edu>
>> > | (And by the way, generic functions are not part of Lisp per se, they're
>> > | part of Common Lisp with CLOS and some other languages that adopted the
>> > | idea, including some OOP languages.)
>>
>> > I have seen this argument a few times around, which I take to mean that
>> > there is some ideal notion of "Lisp" that refuses manifestation in the real
>> > world.
>>
>> The general term "Lisp" is fuzzy, referring to a large (and evolving)
I generally mean Common Lisp w/CLOS when I say "Lisp".
>..cases where Common Lisp isn't used less serious, and IMO it would be a
> bad idea to "deny one's relatives" merely because they aren't mainstream.
Like Dylan. It is my personal opinion that a "Next Generation" of Lisp is needed.
I don't know if Lisp people realize that Common Lisp/CLOS is now 10-15 years old!
We need to learn from the experience, as well as from Scheme,
and the Dylan project too) and JAVA too, and move ahead with a new "Lisp".
I have definite ideas. Mostly I think we need to REMOVE things from CLtL-II,
but also ADD a few things. Build on what is successful,
but don't carry around the baggage of backward compatibility.
The focus should be on practical useability and not "intellectual purity".
The truth is I'd rather USE a 80% "right" system, than have a 98% "right"
system that I can't use in the real world for whatever reason.
I'd rather have a xx MB system that does 80%, rather than have twice as
much xx to "cover" the other 20% or slow down the system by 20% either.
I can start with my belief that we don't need the CLOS MOP
for a new Lisp language to be sucessful.
-Kelly Murray k...@franz.com http://www.franz.com (but speaking for myself)
P. Srinivas
Kelly Murray (k...@math.ufl.edu) wrote:
: Like Dylan. It is my personal opinion that a "Next Generation" of
: Lisp is needed.
: I don't know if Lisp people realize that Common Lisp/CLOS is
: now 10-15 years old!
: We need to learn from the experience, as well as from Scheme,
: and the Dylan project too) and JAVA too, and move ahead with a new "Lisp".
: I have definite ideas. Mostly I think we need to REMOVE things from CLtL-II,
: but also ADD a few things. Build on what is successful,
This is exactly I have been thinking about. But looks like
none of the current common LISP users/makers seem to be
interested in evolving the language. Companies are mostly doing
their own addition to the CL/CLOS than making any efforts for
language definition. Many stall warts of earlier common lisp
are also not interested (Steele, Fahlman etc) Some people moved
out of common lisp and started new language(s).
All of them are probably exhausted by the time they achieved
the near impossible feat of standardising CL that tried to
satisfy everybody.
What we need now is a CL consortium like X consortium that
is funded by all the CL companies like Allegro, Herlequin etc. and
supported by CL user groups and industries that use CL and also
probably with some govt money (NSF?). The consortium then should work
towards EVOLVING CL rather than defining a new language
like dylan. After FORTRAN-77, there are FORTRAN-90 etc.
Why not CL-2000?
CL is now at cross roads. If we miss the chance, it might
die, not because of its weekness as lisp language, but because
of our neglect. 20 years from now somebody will come along
and say tghings such as lisp is not a good language and give
the example of CL that would have disappeared by then.
Just my thoughts
srini
--
URL http://www.cs.usask.ca/homepages/grads/srini/
--------------------
Srinivas Palthepu Email: sr...@cs.usask.ca
ARIES laboratory, Phones: (306) 966-8654 (lab)
Department of Computer Science, (306) 966-4759 (office)
University of Saskatchewan, (306) 373-6724 (home)
57 Campus Dr, Saskatoon, SK, S7N 5A9 Fax: (306) 966-4884
Erik Naggum
* P. Srinivas
| CL is now at cross roads. If we miss the chance, it might die, not
| because of its weekness as lisp language, but because of our neglect. 20
| years from now somebody will come along and say tghings such as lisp is
| not a good language and give the example of CL that would have
| disappeared by then.
Common Lisp has only recently been standardized. give us all a rest while
we're trying to digest the standard, make marginal notes on improvements
and ambiguities, form the intelligent questions we need to ask, and let the
vendors produce completely conforming Common Lisp implementations that can
be _trusted_ for the next 10 years. we're really not in the hurry that
plagues the Windows/Intel world. Lisp projects are big enough investments
to be affected by climate and standards committees. most of the "modern"
stuff out there is small enough to be affected by weather and advertising.
the period following a standard's approval is generally one of resignation.
a lot of people didn't get what they wanted, while others face the task of
building conforming implementations. many very good people will see that
their task is done, and leave, exhausted. but businesses need to recover
the losses they took while being heavily engaged in the standards actitivy
over many years. standardization is like foreign aid -- those who don't
engage in it are short-term winners, but those who set the agenda for a
developing industry can reap vast profits later. but unlike foreign aid,
businesses have definite goals and need to reap those profits before they
can go on. please don't deny them that opportunity.
a hurried deconstruction of the trust and stability that has been built
into the enormous document known as ANSI X3.226 will surely kill Common
Lisp. spread uncertainty, and people won't plan on using your improving
technology until it has, in fact, improved. (something brand new will be
given the benefit of the doubt, but something that works well, but somebody
tells you will be improved, doesn't get that benefit.) in times of rapid
change, the range of people's planning is reduced from decades to months.
please don't inflict that on Common Lisp. (if you don't kill Common Lisp,
you will kill all the incentives to produce conforming implementations.)
yes, there are things I want to change, too, but I trust that I can work
with the vendor of the Lisp I use to get it, and I can code most of it
myself if not. maybe in 5 years' time, I'll be able to join a roomful of
Lisp experts in ANSI X3J13 and be able to contribute something instead of
just being a rebel without a clue. maybe other people will need less time,
but my take on the standard is that not even the brilliant people who
brought it forward to completion know _exactly_ what it says at this time.
having taken part in a standardization process, I know how hard it is to
remember the _final_ of the many wordings used in drafts, and with all the
context that we carry around when writing, there may be inconsistencies
caused by the time of last update, if nothing else. if we hurry this
process, we will undo the careful construction of precise meaning that goes
into requirements in a standard.
ANSI X3.226 is due for a 5-year review in 1999. at the first review of a
standard, it is usual to clarify, not change. at the second review of a
standard, it usually becomes necessary to make changes. that's 10 years.
if a standard is worth having in the first place, 10 years is not a long
time for it to live.
ANSI X3.159 was approved in 1989. it is facing a serious make-over in ISO
these days. the Committee Draft was recently sent out for registration.
the standard should be approved and published within two years, if the
schedules are met. that's also 10 years. (X3.159 is C.)
ANSI X3.159 received an enormous number of requests for clarification in
its first few years. I don't know of any requests for clarification to
ANSI X3J13. (I asked when I ordered my copy of ANSI X3.226.)
as I have argued elsewhere, standardization and evolution should not
overlap. if there is significant evolution, a standardization process
might kill it or we might standardize prematurely. both are bad.
right now, I want most of all to see perfectly conforming implementations
built and sold with significant profits by the very good people who produce
Common Lisp systems. I want this for two reasons: (1) I want to point to
Common Lisp the Standard and say like Guy Steele said in 1990: "Common Lisp
has succeeded". if I can't do that, I really can't argue for the success
of a pie-in-the-sky _improved_ Common Lisp, either. (2) I want to uncover
all the things in Common Lisp that are hard to implement, not used in
practice even it is implemented right, either because it's insufficient or
because it doesn't address the envisioned problems,
I don't think we learn what's right from mistakes, we learn what's wrong,
what _not_ to do. if we can't do something right after such an enormous
effort like that which went into Common Lisp the Standard, I for one would
have very slim hopes of doing it better the next time. after a mistake has
been uncovered in a standard or any specification, you wouldn't believe the
number of "good ideas" that surface from know-it-alls. all the old rejects
crawl out of the woodwork at such a time and some standards aren't improved
simply because the editor has to put a cap on the "good ideas".
if Common Lisp shall be improved, it must be done by people who think what
we have today is _not_ a product of mistakes, but the best that could be
done at the time, and they have to understand the reasons why it was the
best that could be done. only then can they improve on it with any hope of
getting actual improvement, even if it means changing directions somewhat.
the biggest problem with this approach is that people who really understand
something as big as Common Lisp the Standard are very hard to come by.
on a related note, I attempted to post a question on "designators" to
comp.std.lisp a couple months ago. I neither heard from the moderator nor
saw the article posted nor got any replies. if we wish to discuss renewed
standardization of Lisp, I suggest that whoever is in position to revive
comp.std.lisp do so. such debates should not go in comp.lang.lisp, and
probably not in wide open fora like USENET in the first place.
#\Erik
--
Bastard Sex Therapist from Hell: "Read the F*cking Manual!"
Erik Naggum
* P. Srinivas
| What we need now is a CL consortium like X consortium ...
| CL is now at cross roads. ...
I fail to see the truth of your assessments. why do you think we need a CL
consortium and why do you think we are at a cross roads? (both sound too
much like a waste-a-million-bucks "corporate restructuring consultant" to
me. no intent to offend, however.)
Cyber Surfer
With a mighty <30706188...@naggum.no>,
er...@naggum.no uttered these wise words...
> Lisp projects are big enough investments
> to be affected by climate and standards committees. most of the "modern"
> stuff out there is small enough to be affected by weather and advertising.
Another way of looking at is this: only large projects will use Lisp.
I don't know if that's true, but it could be implied by what you're
saying. Perhaps you mean that there are enough big projects to protect
Lisp from the harsh weather and advertising/marketing that afflicts so
many other languages?
I've recently been wondering about Lisp machines, which I'm told were
rather expensive. Well, any "high end" machine will be expensive, but
notions like "value for money" have a different meaning when something
just can't be done for anything less than big bucks. However, that may
put a vendor in a difficult position if the price for doing X drops
below the price at which their workstations can be sold. Perhaps this
is one of the factors, a change in the market, that lead to the demise
of Lisp machines? Similar casualties can be found in the supercomputer
market, following the end of the Cold War.
So, one proposal for a "new lisp" might be nothing more than a price
change. From the discussion here of the relative prices of LispWorks
for Windows and ACL/PC, I doubt it'll be practical for a Lisp vendor
to drop their prices, so it's unlikely to happen. On the other hand, I
agree with you about the lack of a crisis. If such a crisis did indeed
exist, then perhaps a radical price cut might not do any harm.
Another might simply be a name change. This is probably the easiest
proposal to implement, altho a change of syntax might help convince a
few people who might otherwise recognise the language as still being
Lisp. What a giveaway!
A few more minor changes, and you'd have a "new language". I wonder if
anyone has thought of this already. ;) I think that Lisp can certainly
survive a little "weather and advertising". Other languages, like APL
and Smalltalk, are doing it with far fewer changes. Even if you count
J as a "new APL", there are enough old APLs doing new things to make
me suspect that I might not be the only one to think of this.
Of course, a lot of modern languages are still thriving. No doubt they
won't be doing so well 20 years from now. Even C programmers have to
admit that we've got bigger and faster machines now than we did 20
years ago! Time is on our side. The world is slowing waking up,
smelling the coffee (no pun intended), and _liking_ it.
I'm feeling optimistic. That doesn't mean that I think that Lisp isn't
at a crossroads. It means that I think we've got time to do something
about it, that the "crisis" - if one exists - isn't bad for Lisp. No,
it could easily the exact opposite, if we exploit it. If we too
realise that "big" isn't as big as once was, because our machines have
grown up, and are still growing in power. The demands of "small" users
are also growing, giving us a wonderful opportunity to exploit.
> if Common Lisp shall be improved, it must be done by people who think what
> we have today is _not_ a product of mistakes, but the best that could be
> done at the time, and they have to understand the reasons why it was the
> best that could be done. only then can they improve on it with any hope of
> getting actual improvement, even if it means changing directions somewhat.
> the biggest problem with this approach is that people who really understand
> something as big as Common Lisp the Standard are very hard to come by.
I agree about taking care when improving something. However, I'm not
sure that CL is the only starting point. It certainly is if you want
an "improved CL", but an "improved Lisp" might be something quite
different. The price of starting from somewhere else is that more work
may be needed, and this has to be considered. No doubt that was the
case when Apple wanted an "improved Lisp", and I'm looking forward to
using the result, later this year.
However, I'm still very fond of CL, even after all this time. As I
said above, our machines have grown in power, and so I'm less
concerned about the demands of CL on the machine than I might have
been a few years ago, when I first discovered how other people saw the
language - and more importantly, the implementations.
The obstacles are no longer technical ones, but people. Still, it's
amazing what a change of name and syntax can do to pursuade people
that Lisp can solve their problems!
--
<URL:http://www.wildcard.demon.co.uk/> You can never browse enough
Martin Rodgers | Programmer and Information Broker | London, UK
Please note: my email address is gubbish.
Brian Rogoff
On 21 Apr 1997, Kelly Murray wrote:
> I generally mean Common Lisp w/CLOS when I say "Lisp".
>
> >..cases where Common Lisp isn't used less serious, and IMO it would be a
> > bad idea to "deny one's relatives" merely because they aren't mainstream.
>
> We need to learn from the experience, as well as from Scheme,
> and the Dylan project too) and JAVA too, and move ahead with a new "Lisp".
This seems to be a good time to mention that EuLisp also looks like a
reasonable candidate for a "next generation Lisp", in the Common Lisp
tradition.
> I can start with my belief that we don't need the CLOS MOP
> for a new Lisp language to be sucessful.
Meaning what, no MOP at all, or a redesigned MOP? I'd be very cautious
about giving up too much of Lisps' flexibility (and I consider the MOP
a source of that flexibility) because if you remove too much you'll won't
have much more than Java.
-- Brian
Ken Tilton
Kelly Murray wrote:
>
>
> I can start with my belief that we don't need the CLOS MOP
> for a new Lisp language to be sucessful.
>
Egad! No MOP?! Or is that not what you meant?
I need MOP because I wanted to make a certain little hack of mine look
like part of the language, and this transparency is critical enough to
the hack's useability as to be critical to its success.
Lisp's ability to be thus extended is one of its huge "wins", IMHO.
Heck, Graham says it better than I could in his intro to On Lisp.
Did I misconstrue? If no, pritheee, say more on this.
Also interested in what else you would chop from Lisp. I have heard that
many times--almost seems to be conventional wisdom--but I cannot think
of what should be chopped.
No flame. Jes' wonderin'. <g>
Cheers,
Ken
Marc Wachowitz
Brian Rogoff (b...@best.com) wrote:
> This seems to be a good time to mention that EuLisp also looks like a
> reasonable candidate for a "next generation Lisp", in the Common Lisp
> tradition.
EuLisp is surely worth looking at for ideas, possibly even as starting
point if one accepts that further development is necessary, but as a
canditate for a standard Lisp, I don't consider it sufficiently mature.
E.g. the macro system isn't worked out (admitted in definition 0.99),
comparing characters or strings which aren't exclusively alphabetic is
an error (not just implementation-specific, and not even dynamically
detectable except by checking the characters for this before), and there
are no bignums (nor reasonable tools to build them on top of fixnums).
-- Marc Wachowitz <m...@ipx2.rz.uni-mannheim.de>
Harley Davis
m...@ipx2.rz.uni-mannheim.de (Marc Wachowitz) writes:
EuLisp has a well-designed numeric extension system which we used
successfully in Ilog Talk to add bignums and other arithmetic types.
The character comparison business is surely a nit. And the macro
system does need elaboration, but it's an addition rather than a
modification. EuLisp is definitely the right starting point if there
is ever to be a next Lisp generation.
-- Harley Davis
-------------------------------------------------------------------
Harley Davis net: da...@ilog.com
Ilog, Inc. tel: (415) 944-7130
1901 Landings Dr. fax: (415) 390-0946
Mountain View, CA, 94043 url: http://www.ilog.com/