low-level approach

[Brian P Templeton]

mdanish@andrew.cmu.edu writes:

> On Mon, Jan 14, 2002 at 03:03:17PM +0100, Alex Thiel wrote:
>> On Monday 14 January 2002 14:31, Kyle Lahnakoski wrote:
>> > Brian P Templeton wrote:
>> > > Kyle Lahnakoski <kyle@arcavia.com> writes:
>> > > What? Lisp doesn't `naturally' handle strings. Lisp, to me, seems to
>> > > naturally handle sequences (lists, arrays, etc), dictionary-type
>> > > objects (alists, hashtables), and functions.
>> >
>> > Good, take that one step further and see that strings are lists of
>> > characters.  Lisp has many list manipulation functions, and therefore
>> > string manipulation functions.
>> >
>> 
>> Maybe I got that wrong, but I think list in Lisp are objects separated by 
>> spaces. So, in that sense strings are not lists.
>> 
> 
> You're both off.  Most Lisp implementations implement strings as vectors,
> and they certainly do not implement vectors with lists (as Kyle stated
> elsewhere).  Records (structs in CL) can be implemented a number of ways.
> 
Actually, I think that ANSI CL *requires* structs to be implemented
with CLOS (as a metaclass, IIRC).

> Secondly, lists are not 'objects separated by spaces'.  That's called the
> print-representation of a list and you can change that if you so desire.
> A more precise definition might be: lists are chains of cons cells.
> 
> As for this entire sub-thread, if any modern Lisp were truely as you
> describe it, it would be less than useless for most practical purposes.
> I want arrays, structs, classes, hashtables, etc, and I want them
> *efficiently* implemented in native-code compilers.  Of course Java/C++
> and the rest of the crowd were to be compared against that extremely
> backwards and limited form of Lisp then they would seem to be more
> practical.  Fortunately the designers of Common Lisp didn't think that way.
> If you want an example of a Lisp that is closer to what you present,
> see the misnamed "newLISP", http://newlisp.sf.net/ I believe.
> 
> Finally: The fact that all Turing-complete languages can express each other
> does not lead to the conclusion that all Turing-complete languages are
> equally expressive, or have equal semantics.  I can write a Lisp program
> with Turing-machine notation if I first design a Lisp interpreter/compiler
> in Turing-machine notation.  But by the fact that I have to write an
> interpreter/compiler first means that Turing-machine notation does not
> have the same expressiveness as Lisp.  It also means that the semantics are
> different, as I had to change them by writing the interpreter/compiler
> which is quite literally "a function from program to answers" (FOLDOC).
> Your definition of semantic equivalence doesn't fit the definition of
> semantics.  All you've shown is that in a Turing-complete language,
> there is some way to express a program that was already expressed in
> another Turing-complete language.  If a program was already expressed
> in a Turing-complete language then it solves something computable.  And
> that would suit a Turing-complete language.
> 
> Apologies for not responding to the grandparent post, as I wanted to address
> issues from the parent as well.
> 
> -- 
> ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
> ;; Matthew Danish                         email: mdanish@andrew.cmu.edu ;;
> ;; OpenPGP public key available from:        'finger mrd@db.debian.org' ;;
> ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
> 

-- 
BPT <bpt@tunes.org>	    		/"\ ASCII Ribbon Campaign
backronym for Linux:			\ / No HTML or RTF in mail
	Linux Is Not Unix			 X  No MS-Word in mail
Meme plague ;)   --------->		/ \ Respect Open Standards