From: lawrence.g.mayka
Subject: Re: in defense of C
Date: 
Message-ID: <14112@cbnewsc.ATT.COM>
[I have added comp.lang.lisp to the newsgroup list.]

In article <····@skye.ed.ac.uk> ····@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
	···@ihlpf.att.com

Standard disclaimer.

From: Jeff Dalton
Subject: Re: in defense of C
Date: 
Message-ID: <1942@skye.ed.ac.uk>
In article <·····@cbnewsc.ATT.COM> ···@cbnewsc.ATT.COM (lawrence.g.mayka,ihp,) writes:
 >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.

You say this as if it were typical of better compilers on machines
other than SPARCs, such as, maybe, 68020s.  Can they really have safe
CARs and CDRs, without loss of speed, on a 68020?  If so, I would
expect that safety to remain even if I set saftey=0, but that doesn't
seem to be what happens.  Moreover, how many of the SPARC compilers
can do this?  I suspect it's only one or two of them.

-- Jeff
From: Eric Pepke
Subject: Re: in defense of C
Date: 
Message-ID: <542@fsu.scri.fsu.edu>
In article <····@skye.ed.ac.uk> ····@aiai.ed.ac.uk (Jeff Dalton) writes:
> You say this as if it were typical of better compilers on machines
> other than SPARCs, such as, maybe, 68020s.  Can they really have safe
> CARs and CDRs, without loss of speed, on a 68020?

I don't know about the internals of any LISP system other than the ones I 
have written.  In the one I am now writing for the 680x0, one can have 
safe CARs and CDRs without loss of speed.  One has to test to see if it is 
(1) a valid list, or (2) NIL, anyway.  So, one just makes that a test for 
(1) a valid list, or (2) anything else.  In my system, that's testing a 
single bit.  In case 1, do the job.  In case 2, return NIL.

Eric Pepke                                    INTERNET: ·····@gw.scri.fsu.edu
Supercomputer Computations Research Institute MFENET:   ·····@fsu
Florida State University                      SPAN:     scri::pepke
Tallahassee, FL 32306-4052                    BITNET:   ·····@fsu

Disclaimer: My employers seldom even LISTEN to my opinions.
Meta-disclaimer: Any society that needs disclaimers has too many lawyers.
From: Tim Moore
Subject: Re: in defense of C
Date: 
Message-ID: <1990Mar8.115308.6180@hellgate.utah.edu>
In article <···@fsu.scri.fsu.edu> ·····@gw.scri.fsu.edu (Eric Pepke) writes:
>In article <····@skye.ed.ac.uk> ····@aiai.ed.ac.uk (Jeff Dalton) writes:
>> You say this as if it were typical of better compilers on machines
>> other than SPARCs, such as, maybe, 68020s.  Can they really have safe
>> CARs and CDRs, without loss of speed, on a 68020?
>
>I don't know about the internals of any LISP system other than the ones I 
>have written.  In the one I am now writing for the 680x0, one can have 
>safe CARs and CDRs without loss of speed.  One has to test to see if it is 
>(1) a valid list, or (2) NIL, anyway.  So, one just makes that a test for 
>(1) a valid list, or (2) anything else.  In my system, that's testing a 
>single bit.  In case 1, do the job.  In case 2, return NIL.
>

That's the loss of speed that Jeff is talking about. If you assume
that the argument to CAR or CDR is a cons cell or NIL and you have a
low-tags type scheme, then those operations are 1 instruction long on
a 680x0 (or even less: a base-displacement addressing mode). The NIL
case can be handled with a bit of symbol table trickery. A "safe"
C{A,D}R that checks its argument is going to be slower.

>Eric Pepke                                    INTERNET: ·····@gw.scri.fsu.edu
>Supercomputer Computations Research Institute MFENET:   ·····@fsu
>Florida State University                      SPAN:     scri::pepke
>Tallahassee, FL 32306-4052                    BITNET:   ·····@fsu
>


Tim Moore                     ·····@cs.utah.edu {bellcore,hplabs}!utah-cs!moore
"Ah, youth. Ah, statute of limitations."
		-John Waters
From: John Gateley
Subject: Re: in defense of C
Date: 
Message-ID: <113917@ti-csl.csc.ti.com>
In article <···@fsu.scri.fsu.edu> ·····@gw.scri.fsu.edu (Eric Pepke) writes:
|In the one I am now writing for the 680x0, one can have 
|safe CARs and CDRs without loss of speed.
|So, one just makes that a test for 
|(1) a valid list, or (2) anything else.  In my system, that's testing a 
|single bit.  In case 1, do the job.  In case 2, return NIL.
|Eric Pepke                                    INTERNET: ·····@gw.scri.fsu.edu

But this is NOT safe: consider the following code:

(defun foo ()
  (if (car 3)
      (tear-down-the-berlin-wall)
      (bomb-the-soviets)))

Your implementation will bomb the soviets! I understand that your
implementation will not crash due to garbage pointers, but I
don't think "safe" is a good term to apply here.

John
·······@m2.csc.ti.com
From: Eric Pepke
Subject: Re: in defense of C
Date: 
Message-ID: <546@fsu.scri.fsu.edu>
Sorry; I misunderstood the controversy.  I feel like Emily Latella.  
"Never mind!"

Eric Pepke                                    INTERNET: ·····@gw.scri.fsu.edu
Supercomputer Computations Research Institute MFENET:   ·····@fsu
Florida State University                      SPAN:     scri::pepke
Tallahassee, FL 32306-4052                    BITNET:   ·····@fsu

Disclaimer: My employers seldom even LISTEN to my opinions.
Meta-disclaimer: Any society that needs disclaimers has too many lawyers.
From: lawrence.g.mayka
Subject: Re: in defense of C
Date: 
Message-ID: <14236@cbnewsc.ATT.COM>
In article <····@skye.ed.ac.uk> ····@aiai.UUCP (Jeff Dalton) writes:
>In article <·····@cbnewsc.ATT.COM> ···@cbnewsc.ATT.COM (lawrence.g.mayka,ihp,) writes:
> >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.
>
>You say this as if it were typical of better compilers on machines
>other than SPARCs, such as, maybe, 68020s.  Can they really have safe
>CARs and CDRs, without loss of speed, on a 68020?  If so, I would
>expect that safety to remain even if I set saftey=0, but that doesn't
>seem to be what happens.  Moreover, how many of the SPARC compilers
>can do this?  I suspect it's only one or two of them.

You may be right.  The particular compilation "trick" I've seen
relies on the processor hardware to trap a fullword-size reference
to a machine address not aligned on a fullword boundary.  But if,
as I think is true, the 68020 silently satisfies unaligned pointer
references, this particular technique will indeed be ineffective
on that architecture.

All the more reason to upgrade to a RISC-based computer...


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

Standard disclaimer.
From: Johnny Billquist
Subject: Re: Correct LisP (was Re: in defense of C)
Date: 
Message-ID: <12572711825024@AIDA.CSD.UU.SE>
In article <·····@cbnewsc.ATT.COM> ···@cbnewsc.ATT.COM (lawrence.g.mayka,ihp,) writes:
>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.

You might consider me picky, but someone might feel this is
important.

The correct argument to CAR and CDR is *not* lists, but
s-expr (punctuated pairs to be specific). The fact that most
(if not all) LisPs implement lists by punctuated pairs
is a feature you should not rely upon. That is why the
functions FIRST and REST exists. Sure, they do just CAR
and CDR, but what if you stumles upon a LisP which implement
lists in another way? If you should do it *really* right,
CAR and CDR should not be able to work on lists at all,
however convenient it might be.

Anybody who cares to flame can do it to me personally.

======================================================================
Everybody know that the DECstation is a pdp8, which is a RISC,
but where did MIPS computers get into it?

	- Johnny Billquist

····················@AIDA.CSD.UU.SE
======================================================================
From: Tim Moore
Subject: Re: Correct LisP (was Re: in defense of C)
Date: 
Message-ID: <1990Mar12.104518.1412@hellgate.utah.edu>
In article <··············@AIDA.CSD.UU.SE> ····················@AIDA.CSD.UU.SE (Johnny Billquist) writes:
>In article <·····@cbnewsc.ATT.COM> ···@cbnewsc.ATT.COM (lawrence.g.mayka,ihp,) writes:
>The correct argument to CAR and CDR is *not* lists, but
>s-expr (punctuated pairs to be specific). The fact that most
>(if not all) LisPs implement lists by punctuated pairs
>is a feature you should not rely upon. That is why the
>functions FIRST and REST exists. Sure, they do just CAR
>and CDR, but what if you stumles upon a LisP which implement
>lists in another way? If you should do it *really* right,
>CAR and CDR should not be able to work on lists at all,
>however convenient it might be.
>
>Anybody who cares to flame can do it to me personally.

I don't know what Lisps you're refering to, but Common Lisp isn't one
of them. The argument to CAR and CDR is LISTP, which means its either
a cons pair or NIL. How could lists be implemented in some other way?
If some sort of cdr-coding trick or array scheme is used internally in the
implementation, CAR and CDR better still work, or the implementation
is quite broken.

FIRST and REST are for quiche eaters :-) Or, with only have a smiley,
for non-Lisp programmers who are slumming.

>····················@AIDA.CSD.UU.SE

Tim Moore                     ·····@cs.utah.edu {bellcore,hplabs}!utah-cs!moore
"Ah, youth. Ah, statute of limitations."
		-John Waters
From: Ronald BODKIN
Subject: Re: Correct LisP (was Re: in defense of C)
Date: 
Message-ID: <2452@quiche.cs.mcgill.ca>
In article <·····················@hellgate.utah.edu> ··················@cs.utah.edu (Tim Moore) writes:
>I don't know what Lisps you're refering to, but Common Lisp isn't one
>of them. The argument to CAR and CDR is LISTP, which means its either
>a cons pair or NIL. How could lists be implemented in some other way?
>If some sort of cdr-coding trick or array scheme is used internally in the
>implementation, CAR and CDR better still work, or the implementation
>is quite broken.
>
>FIRST and REST are for quiche eaters :-) Or, with only have a smiley,
>for non-Lisp programmers who are slumming.
	The problem with this is that you lose something conceptually.
I don't think anyone will ever invent a lisp where lists aren't cons'd
together (can you imagine how little extant lisp code would work).
However, the author of Anatomy of Lisp, makes a good point that if you
are trying to deal with abstract things (e.g. lists) then don't "pun"
and say "its really just a ..."  The question does arise, however,
whether or not car/cdr are invalid peeking or whether or not they are
so well established that we can consider them overlloaded.  I certainly
use them (if only due to the convenience of cXXXr) and if one wasn't
to use them, then one would have to replace cons and just about anything
which can be used on dotted pairs.  The issue gets more emphatic when
people start to say "well I know that a window structure is just a list:
(x y dx dy textcolor)" and rely on this kind of thing.
	Ron
From: Jeff Dalton
Subject: Re: Correct LisP (was Re: in defense of C)
Date: 
Message-ID: <2035@skye.ed.ac.uk>
In article <····@quiche.cs.mcgill.ca> ·······@quiche.cs.mcgill.ca (Ronald BODKIN) writes:
>However, the author of Anatomy of Lisp, makes a good point that if you
>are trying to deal with abstract things (e.g. lists) then don't "pun"
>and say "its really just a ..."

One certainly shouldn't use CAR and CDR for some abstractions, but
why not use them on lists?  When would you actually allow me to use
CAR and CDR?
From: Wayne Mesard
Subject: Re: Correct LisP (was Re: in defense of C)
Date: 
Message-ID: <53508@bbn.COM>
····@aiai.UUCP (Jeff Dalton) writes:
>why not use them on lists?  When would you actually allow me to use
>CAR and CDR?

Thursdays between 1:30 and 5:30pm.

Wayne();
From: Jeff Dalton
Subject: Re: Correct LisP (was Re: in defense of C)
Date: 
Message-ID: <2057@skye.ed.ac.uk>
In article <·····@bbn.COM> ······@labs-n.bbn.com (Wayne Mesard) writes:
 >····@aiai.UUCP (Jeff Dalton) writes:
 >>why not use them on lists?  When would you actually allow me to use
 >>CAR and CDR?
 >
 >Thursdays between 1:30 and 5:30pm.

Oh, good.  So I can use them _right now_.
From: Charles Noren
Subject: Re: Correct LisP (was Re: in defense of C)
Date: 
Message-ID: <1548@dinl.mmc.UUCP>
In article <····@skye.ed.ac.uk> ····@aiai.UUCP (Jeff Dalton) writes:
>In article <·····@bbn.COM> ······@labs-n.bbn.com (Wayne Mesard) writes:
 > >····@aiai.UUCP (Jeff Dalton) writes:
 >>>why not use them on lists?  When would you actually allow me to use
 >>>CAR and CDR?
 >>
 >>Thursdays between 1:30 and 5:30pm.
 
 >Oh, good.  So I can use them _right now_.
 
Ahh, but are you in the correct time zone?
-- 
Chuck Noren
NET:     ncar!dinl!noren
US-MAIL: Martin Marietta I&CS, MS XL8058, P.O. Box 1260,
         Denver, CO 80201-1260
Phone:   (303) 971-7930
From: Ronald BODKIN
Subject: Re: Correct LisP (was Re: in defense of C)
Date: 
Message-ID: <2487@quiche.cs.mcgill.ca>
In article <····@skye.ed.ac.uk> ····@aiai.UUCP (Jeff Dalton) writes:
>One certainly shouldn't use CAR and CDR for some abstractions, but
>why not use them on lists?  When would you actually allow me to use
>CAR and CDR?
	Its a judgement call.  I think the CxxxR usage is reasonable
(if you like, consider it an overloaded operator) and since there is
not a soul in the lisp world who doesn't know what these do, it is
pretty safe.  Indeed, does common lisp have something ('join') that is
like cons but prepends an object to the head of only a LISP?  If not,
one would have use such also to isolate lists.
		Ron
From: Johnny Billquist
Subject: Re: Correct LisP (was Re: in defense of C)
Date: 
Message-ID: <12574182161036@AIDA.CSD.UU.SE>
In artricle <····@skye.ed.ac.uk> ····@aiai.ed.ac.uk (Jeff Dalton) writes:

>One certainly shouldn't use CAR and CDR for some abstractions, but
>why not use them on lists?

Because lists are an abstraction.

>  When would you actually allow me to use
>CAR and CDR?

When you work on conses of course.

======================================================================
Everybody know that the DECstation is a pdp8, which is a RISC,
but where did MIPS computers get into it?

	- Johnny Billquist
======================================================================
From: Jeff Dalton
Subject: Re: Correct LisP (was Re: in defense of C)
Date: 
Message-ID: <2073@skye.ed.ac.uk>
In article <··············@AIDA.CSD.UU.SE> ····················@AIDA.CSD.UU.SE (Johnny Billquist) writes:
>In artricle <····@skye.ed.ac.uk> ····@aiai.ed.ac.uk (Jeff Dalton) writes:
>
>>One certainly shouldn't use CAR and CDR for some abstractions, but
>>why not use them on lists?
>
>Because lists are an abstraction.

I agree for "some abstractions", so you need an argument about "all
abstractions" or else one about why lists are among the ones that must
be treated abstractly in this way.  I'd already taken the simple
"lists are an abstraction" into account, and as far as I could tell
the benefits of using FIRST and REST in Lisp, and restricting CAR and
CDR to pairs, are chiefly (but not entirely) ideological rather than
practical.

Note that "don't use CAR and CDR on lists" is not the same as saying
"the data structure LIST should not be confused with its representation
as PAIRS".  I agree with the latter but not the former.  I have no
objection to someone using FIRST and REST if they want to, but I
regard it as chiefly a matter of style.

In an earlier message you wrote:

   The correct argument to CAR and CDR is *not* lists, but s-expr
   (punctuated pairs to be specific). The fact that most (if not all)
   LisPs implement lists by punctuated pairs is a feature you should
   not rely upon. That is why the functions FIRST and REST exists.
   Sure, they do just CAR and CDR, but what if you stumles upon a LisP
   which implement lists in another way?

Well, what if you stumble on a Lisp that has CAR and CDR for *lists*
and PAIR-LEFT and PAIR-RIGHT (or something) for pairs?  

In any case, most of the time programmers are not writing Lisp but
some particular kind of Lisp such as Common Lisp or Scheme.  That
something that still counts as Lisp might implement lists in some
other way is not much of a problem in practice.  However, using
CAR and CDR for other data structures built on top of lists or
pairs is another matter.  Nothing I've said should be taken as
an argument against treating those structures abstractly.  Nor
do I think it would necessarily be a bad idea to define a Lisp
in which lists and pairs *were* distinct.

-- Jeff
From: John W. Baugh Jr.
Subject: Abstraction vs representation (was Re: Correct LisP (was Re: in defense of C))
Date: 
Message-ID: <1990Mar12.225234.8416@ncsuvx.ncsu.edu>
In article <····@quiche.cs.mcgill.ca>, ·······@quiche.cs.mcgill.ca
(Ronald BODKIN) writes:
[stuff deleted]
> The issue gets more emphatic when
> people start to say "well I know that a window structure is just a list:
> (x y dx dy textcolor)" and rely on this kind of thing.
> 	Ron

Not unlike the way many oo people use slot names to define a "type."

John (donning my asbestos suit) Baugh
From: lawrence.g.mayka
Subject: Re: Correct LisP (was Re: in defense of C)
Date: 
Message-ID: <14343@cbnewsc.ATT.COM>
In article <··············@AIDA.CSD.UU.SE> ····················@AIDA.CSD.UU.SE (Johnny Billquist) writes:
>The correct argument to CAR and CDR is *not* lists, but
>s-expr (punctuated pairs to be specific). The fact that most
>(if not all) LisPs implement lists by punctuated pairs
>is a feature you should not rely upon. That is why the
>functions FIRST and REST exists. Sure, they do just CAR
>and CDR, but what if you stumles upon a LisP which implement
>lists in another way? If you should do it *really* right,
>CAR and CDR should not be able to work on lists at all,
>however convenient it might be.

Your argument is conceptually appealing, and well describes my own
programming practice:  I use FIRST and REST for the ubiquitous
list, and reserve CAR and CDR for intentional dotted pairs (such
as the constituents of an association list).  Formally, however, I
must quote "Common Lisp: the Language - Second Edition":

	p. 415:  "FIRST is the same as CAR, SECOND is the same
			as CADR..."

	p. 416:  "REST means the same as CDR but mnemonically
			complements FIRST."

Apparently the connection between dotted pairs and lists is deeply
ingrained into Common Lisp.


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

Standard disclaimer.
From: Jeff Dalton
Subject: Re: Correct LisP (was Re: in defense of C)
Date: 
Message-ID: <2034@skye.ed.ac.uk>
In article <··············@AIDA.CSD.UU.SE> ····················@AIDA.CSD.UU.SE (Johnny Billquist) writes:
>The correct argument to CAR and CDR is *not* lists, but
>s-expr (punctuated pairs to be specific). 

Ok so far.

>The fact that most (if not all) LisPs implement lists by
>punctuated pairs is a feature you should not rely upon.

Why not?  Indeed, in Lisp lists just are dotted pairs used
in a certain way.  You might argue that "list" ought to be
more abstract, but it isn't.

>That is why the functions FIRST and REST exists. Sure, they do just
>CAR and CDR, but what if you stumles upon a LisP which implement
>lists in another way? 

Most Lisps don't have FIRST and REST.

A CL or Scheme that implements lists some other way wouldn't be a
conforming implementation.

-- Jeff