bts@evergreen.cs.unc.edu (Bruce Smith) (08/07/89)
I hope someone here can explain the origin of this notion that "Scheme has data types and Lisp doesn't". I have heard several people make this claim over the past couple of years, but never with any concrete evidence nor even a clear explanation of what it's supposed to mean. (It was usually in almost exactly those words, however.) I know a modest amount about these languages and have access to references on them. I have not been able figure out what it is supposed to mean. Most recently, in a discussion of which functional programming language should be taught to students (not at UNC, by the way) I heard that Scheme was to be preferred because compiled Scheme executes much faster than compiled Common Lisp. The reason for that difference? Because, of course, "Scheme has data types and Lisp doesn't."
jeff@aiai.uucp (Jeff Dalton) (08/07/89)
In article <9085@thorin.cs.unc.edu> bts@evergreen.cs.unc.edu (Bruce Smith) writes: >I heard that Scheme was to be preferred because compiled Scheme >executes much faster than compiled Common Lisp. The reason for >that difference? Because, of course, "Scheme has data types >and Lisp doesn't." Some people out there still think "everything in Lisp is a list". Maybe that's it. Of course, it's not true that everything _is_ a list, in Common Lisp or Scheme. Jeff Dalton, JANET: J.Dalton@uk.ac.ed AI Applications Institute, ARPA: J.Dalton%uk.ac.ed@nsfnet-relay.ac.uk Edinburgh University. UUCP: ...!ukc!ed.ac.uk!J.Dalton
nagle@well.UUCP (John Nagle) (08/07/89)
It's more of an MIT vs the rest of the LISP world 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: "As an example, consider the type (array short-float).
Implementation A may choose to provide a specialized representation for
arrays of short floating-point numbers, and implementation B may choose
not to." Serious number crunching with implementation B will probably
be rather slow. There's a faction in the LISP world that feels that
floating point is unimportant. The strongest expression of this feeling
was in the early Symbolics machines, which lacked floating point hardware.
Much of the weakness on typing in Common Lisp reflects lobbying from the
Symbolics faction, which generally supported the idea that everything
possible should be dynamic.
Reading section 4.5 of CLTL (Common Lisp, the Language) will give
you a good feeling of the weakness of the commitment to strong typing
in Common Lisp.
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. Declaring an argument to a function to be of a specific
type may turn off some checking.
John Nagledlw@odi.com (Dan Weinreb) (08/09/89)
In article <13046@well.UUCP> nagle@well.UUCP (John Nagle) writes:
This is very confused. It's hard to know where to begin.
It's more of an MIT vs the rest of the LISP world tradition.
If you are contrasting Lisp and Scheme, it's hard to see how this can
be a conflict between MIT and the rest of the Lisp world. Scheme is
from MIT. Traditionally, the Lisps with the best numeric support,
compared to other Lisps, are *also* from MIT (particularly the NCOMPLR
for Maclisp).
Although Common LISP has data type declarations of a sort, they tend
not to be taken all that seriously by compilers.
This is not the case. Many major Lisp compilers for standard
hardware, such as Lucid and Franz, pay close attention to numeric
declarations, and produce far better numeric code when the
declarations are present.
CLTL is very weak
on this subject:
Yes; this is intentional. The idea is to accomodate both standard
hardware, for which the declarations are needed, and Lisp machines,
for which they are superfluous.
There's a faction in the LISP world that feels that
floating point is unimportant. The strongest expression of this feeling
was in the early Symbolics machines, which lacked floating point hardware.
What? The reason that the Symbolics LM-2 lacked floating point
hardware had nothing to do with a "strong expression of a feeling"; it
was due to marketing timing and economics. The LM-2 was just a
repackaged MIT prototype, and the idea was to get it shipped as fast
as possible, reserving improvements for later hardware platforms.
Machines that were actually designed by Symbolics all had floating
point accelerators, generally based on Weitek floating point chips.
Symbolics typically did very well in Lisp floating point benchmarks.
Furthermore, I know of no "faction" anywhere in the Lisp world that
claims that floating point is unimportant.
Much of the weakness on typing in Common Lisp reflects lobbying from the
Symbolics faction, which generally supported the idea that everything
possible should be dynamic.
That the language should not REQUIRE declarations. And it didn't
require any lobbying; the conventional-hardware faction agreed with
the philosophy that declarations should be optional hints from the
user to the compiler. Guy Steele, Richard Gabriel, and Scott Fahlman
never have advocated mandatory declarations of the types of variables
in Lisp. There was plenty of lobbying during the design of Common Lisp,
but not about this point.
Reading section 4.5 of CLTL (Common Lisp, the Language) will give
you a good feeling of the weakness of the commitment to strong typing
in Common Lisp.
You bet. There is no committment to "strong typing" (typed variables)
in Common Lisp. This is very much intentional.
What people tend to actually implement are systems in which all objects
are "LISP objects", and are still individually allocated and pointed to.
Yes, in the general case.
Defining an array of "short-float" is likely to generate an array of pointers
to LISP objects.
Nope. Not on Symbolics machines and not on the conventional-machine
implementations that I'm aware of. Lisp objects are not always
implemented as pointers; they can be stored "immediately". The
technique of doing this for numbers is nicknamed "inums" and has been
around for at least 15 years.
And none of this has anything to do with the original query, since
Lisp and Scheme are essentially the same in these regards. Scheme
doesn't have typed variables, either.jeff@aiai.uucp (Jeff Dalton) (08/09/89)
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. >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 [...] There's a faction in the LISP world that feels that >floating point is unimportant. The strongest expression of this feeling >was in the early Symbolics machines, which lacked floating point hardware. >Much of the weakness on typing in Common Lisp reflects lobbying from the >Symbolics faction, which generally supported the idea that everything >possible should be dynamic. 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". 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. You might say this is Lisp (and Scheme) vs the rest of the world, except that there are other languages that work in the same way. But I don't think it's MIT vs the rest of the world. MacLisp was known for the efficient numeric code generated by its compiler, for example. CLtL certainly seems to take floating point seriously and describes a reather elaborate set of floating point facilities in detail. There are a number of reason why Symbolics may not have had floating point initially. But floating point is hardly the only case where type information can lead to more efficient code on "conventional machines". Because Symbolics machines have a hardware (microcode?) type dispatch, type declarations don't help on their machines. It could be argued that this is truer to the spirit of Lisp. But in any case, Lisp has never been a strongly typed language, so I don't see how that can be due to Symbolics. > Reading section 4.5 of CLTL (Common Lisp, the Language) will give >you a good feeling of the weakness of the commitment to strong typing >in Common Lisp. It's stronger than in most other Lisps and stronger than in Scheme. > 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. >Declaring an argument to a function to be of a specific >type may turn off some checking. That varies too. But these things also vary in Scheme.
gateley@m2.csc.ti.com (John Gateley) (08/10/89)
In article <9085@thorin.cs.unc.edu> bts@evergreen.cs.unc.edu (Bruce Smith) writes: >I hope someone here can explain the origin of this notion that >"Scheme has data types and Lisp doesn't". Probably this statement refers to older dialects of Lisp which used dynamic scoping, making static type inference difficult. Also, older lisp dialects tended to do everything with cons, as opposed to vectors etc. As for Scheme vs. Common Lisp, the main differences are Common Lisp has more available data types (such as displaced arrays) and CL also gives the user some tools for manipulating/enforcing types (declare, typep, subtypep etc.) >Most recently, in a discussion of which functional programming >language should be taught to students (not at UNC, by the way) >I heard that Scheme was to be preferred because compiled Scheme >executes much faster than compiled Common Lisp. The reason for >that difference? Because, of course, "Scheme has data types >and Lisp doesn't." I don't believe this (and I currently maintain both Scheme and CL compilers). CL could potentially execute slower than Scheme because it has more features (like keyword arguments, sequence functions, etc). However, if you compare CL programs with these feature to Scheme programs which "are the same", then usually the CL programs are more efficient. This is because the compiler knows about the extra features and most of the time has efficient ways of doing them. Hope this helps, John gateley@m2.csc.ti.com
nagle@well.UUCP (John Nagle) (08/14/89)
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
jeff@aiai.uucp (Jeff Dalton) (08/15/89)
In article <13120@well.UUCP> nagle@well.UUCP (John Nagle) writes: >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: [...] Not that SCHEME is really all that different. I knew about all of the things you cite in CLtL. I still don't see how it explains the claim that "Scheme has data types and Lisp doesn't." -- Jeff
les@unicads.UUCP (Les Milash) (08/16/89)
as regards having compiled code go faster, (this brash young hothead) thinks that what scheme has is LEXICAL SCOPING (i think this allows you to generate the addressing sequence for a free variable at lambda-expr-eval-time (i was gonna say "compile-time") and sometimes avoid run-time-type-ck cause you can do the type-ck at "compile-time")
uda@majestix.ida.liu.se (Ulf Dahlen) (08/18/89)
In article <737@skye.ed.ac.uk> jeff@aiai.uucp (Jeff Dalton) writes: >In article <13120@well.UUCP> nagle@well.UUCP (John Nagle) writes: >>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: [...] Not that SCHEME is really all that different. > >I knew about all of the things you cite in CLtL. I still don't see >how it explains the claim that "Scheme has data types and Lisp doesn't." > >-- Jeff Well, the claim is false! __________ Ulf Dahlen Dept of Computer & Info Science, University of Linkoping, Sweden Troskaregatan 51:23 | uda@ida.liu.se S-583 30 LINKOPING | uda@majestix.liu.se, uda@liuida.UUCP SWEDEN | {mcvax,munnari,seismo}!enea!liuida!uda "The beginning is a very delicate time."