Re: pointer elimination in C

ted@crl.nmsu.edu (Ted Dunning)
Fri, 29 Oct 1993 18:43:16 GMT

          From comp.compilers

Related articles
[2 earlier articles]
Re: pointer elimination in C donawa@bluebeard.cs.mcgill.ca (Chris DONAWA) (1993-10-10)
Re: pointer elimination in C doug@netcom.com (1993-10-19)
Re: pointer elimination in C pop@dcs.gla.ac.uk (Robin Popplestone) (1993-10-22)
Re: pointer elimination in C macrakis@osf.org (1993-10-22)
Re: pointer elimination in C henry@zoo.toronto.edu (1993-10-22)
Re: pointer elimination in C mcdonald@kestrel.edu (1993-10-28)
Re: pointer elimination in C ted@crl.nmsu.edu (1993-10-29)
Re: pointer elimination in C rbe@yrloc.ipsa.reuter.COM (1993-11-01)
Re: pointer elimination in C mcdonald@kestrel.edu (1993-11-03)
Re: pointer elimination in C macrakis@osf.org (1993-11-03)
| List of all articles for this month |

Newsgroups: comp.compilers
From: ted@crl.nmsu.edu (Ted Dunning)
Keywords: Lisp, design
Organization: Computing Research Lab
References: 93-10-032 93-10-137
Date: Fri, 29 Oct 1993 18:43:16 GMT



Robin Popplestone <pop@dcs.gla.ac.uk> writes:
  ...
|> on them in the interests of hygene. LISP for example, provides almost
|> nothing but pointers - typically only short integers and possibly short
|> floats will not be pointers.


mcdonald@kestrel.edu (Jim McDonald) writes:
  The general point above about Lisp is partially correct, but in the
  interset of dispelling confusion about Lisp, I should point out that at
  least in Lucid Common Lisp (and presumably any other Common Lisp) many
  datatypes involve non-pointers. In such cases there is a header word,
  which indicates the length of the object and whether it is composed of
pointers or raw bits. (The garbage collector examines such headers when
  deciding whether and how to move objects and/or update any pointers within
  them.)


  Some objects have non-pointers as data:
        code objects (i.e., actual machine-executable code) [also viewed as
        data in lisp!]
        strings
        bignums (indefinitely large integers, or at least up to millions of bits)
        floats
        bit-vectors
        numeric arrays (8-bit integers, 32-bit integers, single floats, double
        floats, etc.)
            ...




Uhh... you just proved pop's point. All of the objects you mention do
exist in memory, but when you actually write lisp code, the values
manipulated are pointers to these objects.


So the point that lisp provides almost nothing but pointers, but does
it very transparently is very well taken. It is so transparent that
you completely missed it!


This is *not* the same as saying that almost all objects may have
pointers inside them.


[good points about pointer hygiene deleted]


      In short, lisp implementors spend a lot of time thinking about ways to
      handle pointers efficiently and robustly, so that users are largely freed
      from doing so.


and even posters to comp.compilers are freed from doing so, too.
--


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.