Stewart Stremler <[EMAIL PROTECTED]> writes: > The kinds of languages that are considered "Lisp-like", one might > presume.
Fair enough. Usually when one writes "LISP," it translates roughly to "something I heard someone else deride back in college," followed by some comment about parentheses. > I've only played with "small" lisp variants, not the huge monsters > like Common Lisp. CL strikes me as the PL/I of the functional > programming world -- is this actually so? Well, CL is most closely akin to C++ or maybe Java in scope and purpose. It's no more functional than imperative; it's a systems programming language supporting various programming styles. You suggest that CL is too large. Most people who use it regularly find it, if anything, too small. > Are there any Lisps/LISPs/lisps/whatnot that _don't_ have at least > that structure? Not that I know of. But it's not the structure per se that's important; it's the interrelated ideas of combining two things (cons), checking if something is atomic (atom, consp), grabbing the first thing of a not-atomic thing (car, first), and grabbing the rest of such a thing (cdr, rest). Such operations can be supported by a cons cell, a two-element vector, a simple structure with at least two fields, or even as closures. These topics pop up regularly on comp.lang.lisp. > Aren't they all built out of cons-cells? No. As these are supplied by the implementation, they can be represented by any means possible. For example, a "SIMPLE-ARRAY"� is likely represented the same way an array is in C. There are other types of arrays that may require more bookkeeping and hence approach something more akin to std::vector<> in C++. But in no case is an array simply a linked chain of cons cells. On some conceptual level there may be little difference between the two, but no sane implementation would make such a choice. > Or it's just that they *can* be? See above. > You are getting confused; I got frustrated and pounced. > I was not dismissing Lisp because it's built -- or some dialects of > it anyway -- from a basic, simple, elegant data-structure. That is, > rather, a strength of that language family. Perhaps so for a strictly academic exercise, but it's that same characterization that leads to dismissing Lisp languages as useless. Common Lisp is pragmatic in nature; like C++, its obligations are toward efficiency. It allows for various styles and concerns to be balanced. One can write completely generic code and rely upon built-in type checking and conversions, but that abstraction and safety comes at a small price. When one needs to avoid that price and can commit to more narrow expectations of operands, Common Lisp honors all sorts of type declarations and optimization tuning to generate assembly code equivalent to the same code written in C.� > I was trying to define what I see to be the defining feature of > Lisp-like languages, namely, that the cons-cell / list is the key > abstraction upon which the language is built. This is amazingly > elegant and powerful. It's not really the cons cell itself that's so useful, but rather that there's at least one construction, access, and iteration protocol built in that can be used to manipulate program code (via macros). But note that the same benefits could be provided with different data structures. It's just hard to come up with anything more simple than the cons cell. > A feature of Common Lisp that isn't in Scheme is not a feature of > Lisp, but only of Common Lisp. True. > When I dismiss Lisp-like languages, it is because the language is > utterly insane, That warrants elaboration. We don't have universal agreement on this insanity. > and the advocates are wont to take credit for absolutely everything > useful in computer science, and fail to claim that FORTRAN is > lisp-like due only to the distressing fact that FORTRAN came first. That sort of credit doesn't interest me, for one. I don't care who came first; I care about who is most complete, accessible, and productive. For me, that's Common Lisp. If it had been invented last year as a copy of "Visual J# Script++" I wouldn't like it any less. [...] > However, since you appear to be an expert in Common Lisp, No, I am definitely not an expert. I'm beyond novice stage, having used it for a few years now, but I can barely post to comp.lang.lisp without serious trepidation. I spoke up here because the level of misconception seemed surprising even to me, and I wanted to encourage some basic research before dismissing the language for its undeserved myths. > perhaps you can answer a question that has just popped into my mind > -- is Common Lisp an image-based language? It can be, and usually is, but the language specification does not mandate it. Every Common Lisp implementation I've used or read about allows one to dump or load an image. In fact, the basic CL runtime is usually provided as as an image as well; it just happens to not contain anything added by the user -- yet. Footnotes: � http://www.lispworks.com/documentation/HyperSpec/Body/t_smp_ar.htm � http://www.gigamonkeys.com/book/conclusion-what-next.html (Search for "For a simple example".) -- Steven E. Harris -- KPLUG-List mailing list [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
