[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Snapped Elastic
- To: Scott.Fahlman at CMU-10A
- Subject: Re: Snapped Elastic
- From: Guy.Steele at CMU-10A
- Date: Thu ,13 Nov 80 13:38:00 EDT
- Cc: lisp-forum at MIT-MC
Actually, I didn't even have in mind all the hair of actual versus
allocated sizes, only a primitive that could shrink a vector, but never
grow it.
What would you think of a medium-level primitive that would attempt
to resize a vector, returning it is it succeeded and returning false
if it failed? Then different implementations could have different
criteria for whether it could resize a vector in place. User-level
code would do:
(DEFUN VECTOR-RESIZE (VEC NEWSIZE) ;may not return EQ pointer
(OR (LOW-LEVEL-FAST--BUT-NOT-GUARANTEED-RESIZE VEC NEWSIZE)
(DO ((V (MAKE-VECTOR NEWSIZE))
(N (MIN (VECTOR-LENGTH VEC) NEWSIZE))
(J 0 (+ J 1)))
((= J N) V)
(VSET (VREF VEC J) V J))))
Then whatever cases are handled well by the low-level guts would be speedy
and result in an EQ pointer, and otherwise the user code would have to
deal with the copying. Some implementations would never allow resizing;
some would always win, by using forwarding pointers; some would win when
decreasing but not increasing; some would win for any variation below
the initially allocated size; and so on.