low-level approach

[mdanish@andrew.cmu.edu]

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.

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' ;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;