Re: "Scheme has data types and Lisp doesn't."

[John Nagle <usc!apple!well!nagle@bloom-beacon.mit.edu>]

In article <711@skye.ed.ac.uk> jeff@aiai.uucp (Jeff Dalton) writes:
>In article <13046@well.UUCP> nagle@well.UUCP (John Nagle) writes:
>>     It's more of an MIT vs the rest of the LISP world tradition.

       I think of MIT as favoring strong typing and efficient implementation
of math, following the Maclisp tradition.

>>Although Common LISP has data type declarations of a sort, they tend
>>not to be taken all that seriously by compilers.  CLTL is very weak
>>on this subject [...] 
>I find this explanation rather strange.  For one thing, Common Lisp
>has more in the way of declarations than does Scheme, so I don't see
>how Common Lisp's weakness explains why someone would say "Scheme
>has data types and Lisp doesn't".

     Common LISP has lots of declarations.  But the programmer isn't
required to provide them and the compiler implementor isn't
required to make them do much.  CLTL: "Declarations allow you to specify
extra information about your program to the LISP system.  With one
exception, declarations are completely optional and correct declarations
do not affect the meaning of a correct program."  [CLTL, intro to chapt. 9].
Not that SCHEME is really all that different.

>Neither Lisp nor Scheme (if we're going to pretend for the moment that
>Scheme isn't a kind of Lisp) are strongly typed.  Both use dynamic
>typing.  This is not something introduced by Common Lisp, nor is it
>something that's changed in Scheme.

      Common LISP implementations typically use dynamic typing, and it
is mandatory that dynamic typing be supported.  The syntax is defined
for strong, static typing.  But it isn't necessarily connected to
anything.  In theory, one could have a Common LISP system with typing
as strong as Ada's, while retaining the dynamic typing facilities
for the occasions on which they are needed.  This is consistent with
the language definition, although not with LISP history.


>>     What people tend to actually implement are systems in which all objects
>>are "LISP objects", and are still individually allocated and pointed to.
>>Defining an array of "short-float" is likely to generate an array of pointers
>>to LISP objects.
>
>That varies from implementation to implementation.

      Yes. KCL does it the slow, general way.  Lucid did until at least
late 1987, I think.  I happened to be doing a number-crunching implementation
in LISP in 1987, and was irked that I couldn't get efficient matrix math
in any available LISP for Sun 3 iron.

     					John Nagle