Issue: BIT-ARRAY-FUNCTIONS (version 6)

[David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>]

    Date: Mon, 19 Jun 89 18:39 EDT
    From: Barry Margolin <barmar@Think.COM>

	Date: Mon, 19 Jun 89 13:44 EDT
	From: David A. Moon <Moon@stony-brook.scrc.symbolics.com>

	    Date: Mon, 19 Jun 89 13:31 EDT
	    From: Barry Margolin <barmar@Think.COM>

	    I'd like to suggest an additional change, which seems to be consistent
	    with the attitude about use of bit vectors expressed in the proposal.
	    The BIT and SBIT functions should return 0 if asked to access outside
	    the bit array.  This would maintain the tautology

		    (bit (bit-XXX v1 v2) n) == (logXXX (bit v1 n) (bit v2 n))

	    If slowing down these functions (they'd be the only array accessors
	    REQUIRED to check the dimensions) is considered unacceptable, then a new
	    accessor should be added.

	I don't like this idea.

    Could you elaborate?  Why is it that you like the idea of assuming 0
    elements on the end when combining bit vectors, but not when accessing
    them?  Either you think of them as being infinitely padded with zeros,
    or you don't.

I disagree with the last sentence.  I don't think the BIT function is in
the same category as the BIT-AND function, I think of it as being at a
different conceptual level.  It's a matter of taste and intuition, so
I don't think I can explain it better, and I don't expect you to be
convinced.  I'm only saying what I don't like, not what I think you
ought to dislike.

Then again, I have never used the BIT function and would propose to
remove it from the language if I thought that had a chance of passing.
Same for SBIT, CHAR, SCHAR, and SVREF.

    I'm not sure I really grasp the whole motivation for this change.
    Anyone who needs the kind of functionality being proposed can already
    get it by using the boolean integer functions.  They already provide the
    infinitely-padded-with-zeroes feature.  In fact, they also provide
    infinitely-padded-with-ones, also, in the form of negative numbers.

The discussion that originally prompted this pointed out the reason why
the boolean integer functions aren't always adequate.  I forget now what
it was, maybe the lack of control over consing, or maybe something more
fundamental.  It looks like all that got into the writeup was a pointer
to that discussion, not a summary of it.  Of course, that's the motivation
for having the BIT-AND etc. functions in the language in the first place,
more than the motivation for making this change to them.