On Thu, 7 Dec 2000, Ben Tilly wrote:

> Glancing at array.c and string.c the reason for this is
> obvious.  Strings in Ruby take up exactly the room
> allocated for them.  Arrays are in a buffer where they
> have to be aligned on the left with the buffer but there
> is room on the right.  Therefore any playing with the
> boundaries of a string forces you to recopy the whole
> thing.  And likewise any playing with the left side of an
> array forces you to recopy it.  (So shift should also be
	[...] 
> If Ruby wants good performance on this set of operations
> (trust me, people coming from Perl are going to be very
> likely to call shift a lot without realizing that it is
> slow) it needs to use a buffering system closer to that
> which Perl uses.  In ruby.h this would mean adding a
> "capa" field to RString and an "offset" field to RArray,
> and adding logic in the C files to use these in an
	[...]

This seems odd to me, if I understand you.  It sounds like
adding in extra padding so you can use it if you need it.

I think the system of cons cells in lisp is quite nice.
This makes extending either end easy, and copes with nested
objects well.

http://www.gnu.org/manual/elisp-manual-20-2.5/html_node/elisp_79.html

and associated pages explain this.  I don't know if it is
the best way to do it, but it could mean that iterating
through strings would use the same code as arrays,
substitution into strings would be easy. Making the list
doubly linked would ease bidirectional iteration at the
cost of memory.  Fast access by [] would be more difficult,
which may be the reason for these other methods.
> 
> Cheers,
> Ben

	Hugh
	hgs / dmu.ac.uk