Re: Removing scm_vector_set_length_x ?

[Marius Vollmer]

Dirk Herrmann <address@hidden> writes:

> On 11 Oct 2000, Marius Vollmer wrote:
> 
> > > I have removed all calls to scm_vector_set_length_x from libguile.
> > > Thus, the function could now be deprecated or removed immediately.
> > > Changing the length of an existing vector is something that should
> > > not be supported by the API, IMO.
> > 
> > Why not?  I think it would be convenient thing to have, even on the
> > Scheme level.  What is strange about it?
> 
> It's a problem with threading:

Ahh, threading.  I think I understand the problem, but I don't like
it.  I find myself being more and more convinced that cooperative
threading within a Unix process is good enough (with proper behaviour
of blocking operations such as read/write and rethinking of signals)
and presents much less problems than fully preemtive threading.

But that's only as an aside.

I'm now convinced that we should remove scm_vector_set_length_x.

> And now to the problem: How do you use a vector?  You typically
> extract the pointer to the elements and work on those, while still
> making sure that the vector object is gc protected.

We could deprecate that, by deprecating SCM_VELTS and providing
SCM_VELT(vec,index) instead, for example.  But I agree that just
disallowing vector resizing is more attractive right now.

> I don't think it's a good thing if
>
>   (= (vector-length v) (begin (f v) (vector-length v)))
>
> is not guaranteed any longer, but depends on what f happens to do with v.

We already have the problem with

    (= (length l) (begin (f l) (length l)))

but people are prepared for it.  You do need some kind of owner ship
protocol to regulate who is allowed to change list structures.  The
same could be done for vectors.  But maybe it shouldn't.