From ...
From: Erik Naggum
Subject: Re: Windows LISP Interpreter?
Date: 1997/11/06
Message-ID: <3087840295402548@naggum.no>
X-Deja-AN: 288179397
References: <878404942.17157@dejanews.com> <34602CCD.D53B3A14@ctp.com> <878773423.11750@dejanews.com>
mail-copies-to: never
Organization: Naggum Software; +47 8800 8879; http://www.naggum.no
Newsgroups: comp.lang.lisp
* bamboo7431@hotmail.com
| Thanks to everyone who replied to my original article. I was expecting a
| storm of replies but not that big :) But all I got from your posts is: 1)
| Total ANSI LISP cannot be implemented by one person. 2) LISP interpreters
| should not be written at all since there is plenty of them. 3) Beginners
| and "Dummies" should not even try to write a single line of code before
| reading 10+ books on LISP (published in 1975-1985).
(1) and (2) appear reasonable, but I haven't seen anybody say or imply
anything that could even remotely support the highly unreasonable (3), so I
assume you are getting a tad defensive on behalf of beginners and dummies.
(BTW, I would _never_ buy anything marketed to "dummies" even if I were all
new to a field. people who buy such books obviously think of themselves in
terms I find much too self-deprecatory and self-debasing.)
in a reasonable society, experience and knowledge are respected, and those
who wish to take part in any activity enjoyed by others _expect_ to have to
learn what the others know to enjoy it fully, not just out of respect for
those others whose time and enjoyment they do not want to waste or destroy,
but out of a personal sense of esteem in mastering something and reaching a
level of _informed_ and _competent_ enjoyment.
in a sick society, experience and knowledge are frowned upon, arrogant
ignorance encouraged, and those who wish to take part in any activity
enjoyed by others _demand_ to be taken seriously when they know nothing and
are prepared to do nothing, complete with the right to accuse everybody who
knows more than them of being elitist and actively hostile to beginners.
I wonder what happened to the concepts of education, training, and gaining
experience before attempting advanced stunts.
| What about the question I had in my original post (about implementing
| ANSI CL or at least its subset in terms of a small core)? At this point
| performance does not matter - my point is that working public domain
| Windows product would soon be enhanced by everyone who will work with it.
I believe this point is contradicted by fact.
part of the reason, I believe, is that if you want to program in Lisp, it's
because you _don't_ want to take detours down to the basement every few
hours to fix some plumbing detail or adjust the electrical system or any of
the other stuff that C programmers and Linux hackers seem to enjoy spending
a lot of time on. some people actually fancy the notion that computers
should not crash on them but just _work_, and I believe there are more of
these people working in higher-level languages than in low-level languages
-- and not just Lisp, but anything other than C and C++ and their friends.
| If such public domain implementation exists, could someone provide the
| URL for it? If not, does it mean that each ANSI CL system should
| implement all 1000+ operators?
I'm not aware of any such public domain "library" of ANSI CL source, but I
wonder why you find this so strange. it's actually like this in every
other language, too, and operating system, and major application. in every
high-level language, any implementation will have to establish a number of
conventions and adhere strictly to them. conventions will not mix easily
with each other. you need look no further than the conventions surrounding
the passing and returning of aggregate objects (structs) in C: there are at
least three very different ways to utilize system resources like memory and
registers. different programming languages have traditionally implemented
function calling conventions differently: Fortran, Pascal, and C being the
three major ones. note that C _broke_ with the predominant convention of
its time in that it required the _caller_ to adjust the argument stack.
there's also a non-trivial interaction between types, functions and
optimizing compilation that makes an implementation of all the Common Lisp
functions on a "naive" substrate less useful than it appears to be. in C,
you would have just one function and it would get called to do its job. in
Common Lisp, a function in the standard is more the advertized interface of
functionality. the function named `car' must exist, but in all likelihood
it is compiled to a single instruction. an `aref' is probably inlined
similarly. for other functions, you can probably expect there to be
several different versions depending on the compilation switches you have
given. Common Lisp has the notion of "safe code", but if you request
unsafe code and high performance, you shouldn't still be using safe code in
the functions you call.
also, the number of external symbols in the COMMON-LISP package are dwarfed
by the number of symbols in a decent implementation of Common Lisp. e.g.,
in a full Allegro Common Lisp with Common Windows, CLIM 2.1, and the
Composer, there are almost 32,000 symbols in 45 packages, and 21,000
function objects in the image. in a compiler-only Allegro CL, there are
13,500 symbols in 24 packages and 6,000 function objects. somehow, I don't
think there's much benefit to having the 752 functions in the COMMON-LISP
package taken from a public domain source base.
it took me quite a while to realize that Common Lisp qua language is
_small_ compared to a serious implementation of it, and that this is also
true of most other serious languages and attendant environments. the
smaller the language, in fact, the more external (extralingual?) features
and facilities are needed. once this realization has sunk in, it becomes
even less likely that encouraging people who want to learn the language by
implementing it themselves _outside_ of an existing environment is a good
idea. as I said above: it's all the stuff the programmer _doesn't_ have to
do that gives Lisp its major appeal.
#\Erik
--
if you think this year is "97", _you_ are not "year 2000 compliant".
see http://sourcery.naggum.no/emacs/ for GNU Emacs 20-related material.