Xref: utzoo comp.lang.scheme:1135 comp.lang.lisp:2863
Path: utzoo!attcan!uunet!aplcen!uakari.primate.wisc.edu!ames!pacbell!att!cbnewsc!lgm
From: lgm@cbnewsc.ATT.COM (lawrence.g.mayka)
Newsgroups: comp.lang.scheme,comp.lang.lisp
Subject: Re: in defense of C
Message-ID: <14112@cbnewsc.ATT.COM>
Date: 5 Mar 90 15:19:48 GMT
References: <1903@skye.ed.ac.uk>
Reply-To: lgm@cbnewsc.ATT.COM (lawrence.g.mayka,ihp,)
Organization: AT&T Bell Laboratories
Lines: 40

[I have added comp.lang.lisp to the newsgroup list.]

In article <1903@skye.ed.ac.uk> jeff@aiai.UUCP (Jeff Dalton) writes:
>Besides, since when does Lisp make such checks.  Sure, most Lisps
>probably check array bounds, but most do not check whether CAR and
>CDR are really being applied to conses (just for example).

On Lisp-directed processor architectures, dynamic type checks are
(typically) uniformly applied, often in parallel with the
computation of the most-common-case result.  On conventional (C-
and Fortran-directed) architectures, Common Lisp vendors typically
offer a range of safety/efficiency tradeoffs.  One can then choose
a tradeoff according to the needs, or the stage of development, of
one's application.

One of the most important quality measures of a Common Lisp
compiler is the level of safety it supports without an undue
sacrifice in execution speed.  The better CL implementations score
quite highly on this scale, especially on newer processor
architectures such as SPARC.  For example, the better compilers
indeed ensure that CAR and CDR are only applied to lists, without
a loss of execution speed and even though a CL implementation must
permit one to apply CAR and CDR to the symbol NIL.

>As GJC notes, Lisp programmers have developed ways to deal with
>this, as have C programmers.

I venture to say that generally, Common Lisp programmers compile
unsafe code only when they have to (e.g., when the absolute
maximum execution speed is called for, or when forced by
circumstances to use an inferior CL compiler), not because they
like it.  Unsafe code is not an integral part of the culture or a
badge of pride as, one might say, it seems to be for C.


	Lawrence G. Mayka
	AT&T Bell Laboratories
	lgm@ihlpf.att.com

Standard disclaimer.