Subject: Re: Windows LISP Interpreter? From: Erik Naggum <clerik@naggum.no> Date: 1997/11/06 Newsgroups: comp.lang.lisp Message-ID: <3087840295402548@naggum.no> * 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.