Nikodemus Siivola <nikodemus@...> writes:
> 2009/4/25 Tobias C. Rittweiler <...>:
> > The patch does not guard against [violating DECLARE type declarations]
> Inserting casts for things like that would be possible, but not in the
> general case: replace the (SETF CAR) with a call to FOO that does the
> same, and the compiler has no way to guard against it. (Ok, I suppose
> we could check the type again after any unknown call, but that would
> suck pretty badly -- not to mention that type TYPE-ERROR would arise
> after the damage has been done, which would be pretty wierd.
> The only thing that I can think of that could be done would be to
> never trust a specific CONS type or the dimensions of a non-simple
> ARRAY is safe code -- even if it is declared. Hm, yes, that might be a
> good idea.
Yes, or only trust it if you can be sure it's not going to be
violated. (E.g. the variable is only passed to accessors functions,
later perhaps to any function that is declared to be
flushable---although I don't know how accurate the information is in
Bonus point if you can make it emit a note saying "forced to downgrade
from more specific type (CONS FIXNUM (CONS FIXNUM NULL)) to LIST." on
appropriate optimization settings.
> ...and note the wierdness of CONS and non-simple ARRAY types in the
> manual, of course...
Section? (I looked through 3.2 but couldn't find it.)
It would be useful if the manual was not only available
one-site-per-node, but also everything-in-one-page.
> > [DESTRUCTURING-BIND on return value declared to be (CONS FIXNUM ...)]
> > For me that's the most obvious use case for specifying compound list
> > types.
> I believe the most common case is when you need to store pairs of
> fixnums and want to save one word as opposed to using (COMPLEX
> I'll probably merge this patch as 1.0.28.early, and people who use
> (CONS FIXNUM) can then test it to see if they get performance
> regressions in their applications.
I've got a DEFTRANSFORM on PROPER-LENGTH-OF-LENGTH so DESTRUCTURING-BIND
will complain at compile-time if the lambda-list does contain too many,
or does not contain enough required parameters.
(destructuring-bind (x y) (compute-fixed-list ...)
with the COMPUTE-FIXED-LIST of my previous message would result in a
code deletion note.
Furthermore, I modified DEFSTRUCT to use compound CONS specifiers for
(defstruct (foo (:type list))
(a :type fixnum)
(b :type fixnum)
(b :type fixnum))
Now if you later add a new slot, or remove one, *all* the
DESTRUCTURING-BINDs in my code will emit notes, and I can easily fix
That's a nice poor man's algebraic-datatype like feature.
Is that a good enough use case to see incentive to extend your work to
make it probably derive types in DESTRUCTURING-BIND? :-)