[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (Version 9)
- To: Jon L White <firstname.lastname@example.org>
- Subject: Re: Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (Version 9)
- From: masinter.pa@Xerox.COM
- Date: 11 Jan 89 21:34 PST
- Cc: Masinter.pa@Xerox.COM, cl-cleanup@Sail.Stanford.Edu
- In-reply-to: Jon L White <email@example.com>'s message of Wed, 11 Jan 89 17:48:32 PST
JonL, I was not suggesting a requirement that implementors would have to
upgrade different arrays differently. Why would Lucid oppose allowing other
implementors to take a different implementation strategy? Certainly your
compiler optimizations could continue to work based on your assertions
about your own array implementation types.
> but be more strict about larger arrays. The major part of the
> ("Change the meaning of (TYPEP <x> '(ARRAY <type>)), where <type> is
> *, to be true if and only if <x> is an array that could be the result
> giving <type> as the :element-type argument to MAKE-ARRAY.") could be
>No, because you would have to say what the other arguments to MAKE-ARRAY
You know what the other arguments to MAKE-ARRAY are by looking at <x>.
Implementation A upgrades integer ranges to (SIGNED-BYTE n) for n a power
of 2 up to 32, and then T.
Implementation B upgrades integer ranges to (SIGNED-BYTE 32) and then to T.
Implementation C upgrades simple small (say, less than total-size 2) arrays
like B, and other arrays like A.
You can implement (C:TYPEP object type) by (if (simple-small-p object)
(b:typep object type) (a:typep object type)). I.e., TYPEP need not merely
be implemented by ARRAYP + a test on ARRAY-ELEMENT-TYPE.