Account Options

  1. Sign in
The old Google Groups will be going away soon, but your browser is incompatible with the new version.
Google Groups Home
« Groups Home
Message from discussion singleton references (Ex: Re: Constants and DEFCONSTANT)
The group you are posting to is a Usenet group. Messages posted to this group will make your email address visible to anyone on the Internet.
Your reply message has not been sent.
Your post was successful
 
From:
To:
Cc:
Followup To:
Add Cc | Add Followup-to | Edit Subject
Subject:
Validation:
For verification purposes please type the characters you see in the picture below or the numbers you hear by clicking the accessibility icon. Listen and type the numbers you hear
 
Vassil Nikolov  
View profile  
 More options Apr 5 1999, 3:00 am
Newsgroups: comp.lang.lisp
From: Vassil Nikolov <vniko...@poboxes.com>
Date: 1999/04/05
Subject: singleton references (Ex: Re: Constants and DEFCONSTANT)
In article <sfwzp4pj9op....@world.std.com>,
  Kent M Pitman <pit...@world.std.com> wrote:

> Vassil Nikolov <vniko...@poboxes.com> writes:

> > how about a zero-dimensional array as an idiom for a half-cons
> > (i.e. a singleton reference)?

> As a rule, arrays are higher overhead to access than conses.  And they
> have to have header info that says what their dimension size is, so
> that would use up the space you saved by going into array--maybe even
> more.  I don't know how much overhead arrays have on them in typical
> implementations but they do use more storage than just the element
> memory itself, I'm pretty sure.

Oh, yes.  Of course it is highly implementation dependent, but my
`generalised implementation-independent' estimate is 8 bytes (which
is useful only to maintain some _rough_ mental idea of storage costs).

I hope I mentioned it that I was aware of higher costs---the reason
why I still put forward 0d arrays has to do with expressing intent,
see below.

(In fact, assuming 64 bits of header and, in a 64-bit architecture,
64 bits per reference, a simple array with room for a single element
would occupy as much storage as a cons cell.  But this is just
hypothetical.)

> It might help a little if you knew the 0d array was also simple.(I
> never saw a displaced or adjustable 0d array, but I think it's
> possible in principle. :-)

It ought to be possible to have a 0d displaced array.  But adjustable?
Don't ask, don't tell...

> Maclisp had the HUNK datatype which was the right thing.  It was a
> generalized cons that had however many parts you wanted.  A 1-element
> hunk was still of type HUNK2 (represented identically to CONS, but in
> a different allocation space) but had a filler in one of its slots that
> said "nothing here".  I was sad hunks went away, though they really
> were a kind of hack ... I guess the main reason they went away was that

I had known about Maclisp's hunks only from comp.lang.lisp.  They do
look like what I want but I know I should not be holding my breath for
their re-introduction into the language.

> they had been co-opted as a low-level implementation substrate for
> implementing class-like things in pre-class-system days, and when a
> real class data structure came along, it wasn't as needed.  I suppose
> you could use a structure with only one slot, but since it would have
> a header saying the type of the structure, it would take up the same
> space as a CONS anyway.  Just can't quite win.

In theory at least, an implementation could have a specific tag for
a singleton reference so that the reference itself does take half the
space for a cons cell.  But even though it could, I don't expect that
it would, it being too much trouble for something that's rarely needed.

But, before worrying about storage, I worry about a clear expression
of my intent to use something as a singleton reference.

(1) Using a cons is most efficient but is one of those `cancer of the
    semicolon' cases:

    (let ((ref (cons foo nil)))  ;the cdr will not be used
      ...)                       ^^^^^^^^^^^^^^^^^^^^^^^^^

(2) Using a structure makes for a program where adding a second slot
    is an easy change to the program: a structure with just one slot
    still sort of implies that a second slot might appear some day,
    and I don't want that.  For the same reason, I want a _zero_
    dimensional array, not a vector of length 1: (AREF REF) means
    there is just this one, period, while (AREF REF 0) again sort of
    implies that one day we might see (AREF REF 1) etc.

(3) Of course I could say

    (defstruct ref obj)  ;thou shalt have just this slot

    but on the other hand sometimes I (perhaps others too) prefer
    idioms to Doing the Right Thing by introducing abstractions
    for each and every purpose and thus cluttering the program
    with defining forms and the concept space with datatypes,
    accessors, etc.  (For the same reason I am not very keen on
    wrapping calls to CONS and FIRST in calls to MAKE-REF and REF.)

Anyway, this exercise is not worth more than the proverbial two cents
since even if `efficient singleton references' makes it to a wish
list it would have very nice(1) priority...

I also remember the case of Algol-68, which among other things tried
to Get references Right, I believe.

Vassil Nikolov <vniko...@poboxes.com> www.poboxes.com/vnikolov
(You may want to cc your posting to me if I _have_ to see it.)
   LEGEMANVALEMFVTVTVM  (Ancient Roman programmers' adage.)

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    


 
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.