From ... From: Erik Naggum Subject: Re: C++ briar patch (Was: Object IDs are bad) Date: 1997/05/28 Message-ID: <3073836438931858@naggum.no>#1/1 X-Deja-AN: 244549932 References: <5mfos6$ngp$1@masala.cc.uh.edu> <5mhh8h$gkq@web.nmti.com> <86wwojd3jg.fsf@g.pet.cam.ac.uk> <5mht5n$pk3@web.nmti.com> mail-copies-to: never Organization: Naggum Software; +47 2295 0313; http://www.naggum.no Newsgroups: comp.lang.scheme,comp.lang.lisp,comp.lang.misc,comp.lang.functional,comp.lang.c++ * Peter da Silva | But those things don't define what Lisp is. They're elaborations. Lisp, | at the bottom level, is the list. The ability to express programs and | data in the same format, and manipulate it using list operations, is what | really defines a language as being part of the lisp family. it's a persistent myth that Lisp has only one data type, the list. (obviously, there must be a list of _something_, but hey, myths don't generally respect logic any day of the week.) I don't think it's wise to keep that myth alive. another persistent myth is that Lisp programs are lists. they aren't. Lisp _source_ code uses lists. _compiled_, it is another data type, like a code vector, which includes native machine code or perhaps byte code. what defines the Lisp family to me, after I have had the opportunity to refine my definition over time, is READ/WRITE CONSISTENCY. all languages in the extended Lisp family have this in common, and no languages outside the Lisp family can sport anything like it. that is, the ability to print (write) some object out in text form and read it back in again (or the other way around, depending on where the object is originating). #\Erik -- if we work harder, will obsolescence be farther ahead or closer?