Re: The future: accessing vectors, arrays, etc from C

From: Marius Vollmer <marius.vollmer@uni-dortmund.de>
Cc: guile-user@gnu.org
Subject: Re: The future: accessing vectors, arrays, etc from C
Date: Tue, 11 Jan 2005 19:01:44 +0100	[thread overview]
Message-ID: <ljzmzfx2t3.fsf@troy.dt.e-technik.uni-dortmund.de> (raw)
In-Reply-To: <41E06A7B.8050106@ossau.uklinux.net> (Neil Jerram's message of "Sat, 08 Jan 2005 23:19:23 +0000")

Neil Jerram <neil@ossau.uklinux.net> writes:

>> A change in representation of an array might happen when the copy for
>> a copy-on-write array takes place, or when the first 16-bit Unicode
>> character is stored in a 8-bit string.
>
> Just to check understanding: is it correct that:
>
> - all such changes have to be driven from Scheme code?

Hmm, I'm not sure what you are getting at.  Certainly C code can
trigger these changes as well, but they do not happen spontaneously.

For example, you might get an error about not being allowed to change
a reserved array when you try to grow a vector while it is being
sorted in another thread.  The thing to do then is to use some
synchronization (such as a mutex) to prevent this situation.

> - such changes do not affect the arrays obtained by C code through the
> scm_*_array_handle_*_elements functions?

Right.  Those arrays are 'reserved' while C code accesses them and you
can't change them in a way that would invalidate the pointers that C
code is using.

>> It will be more tedious to use than the old one mainly because it is
>> more general, something which has nothing to do with allowing
>> representations to change: When using the new API, your code must be
>> able to deal with non-contiguously stored vectors, while previously
>> you could just assume that all vectors are stored contiguously.
>
> This worried me when I first read it, but in fact I think the only
> increase in tediousness is that the increment from one element to the
> next may not always be 1.  But it will always be some constant.  Is
> that right, or am I missing some other kinds of tediousness? :-)

That is exactly right.

(There are any number of schemes to store arrays in memory, just think
about sparse or band matrices, and we can't offer them all.  I think
the current compromise by Guile is the right one.)

> I think this delta is OK, personally.  And in practice many
> applications will be able to get away with asserting that the
> increment is 1, by simplying avoiding array mapping in more than one
> dimension.

Hmm, no, even vectors can have increments != 1.  The diagonal of a
matrix would be an example.

> Even so, I think we could usefully make a public statement (perhaps by
> adding it to the manual) reflecting the apparent consensus from this
> discussion, namely...

Yours is a very good summary, but I myself wouldn't want to put it in
the manual... just let reality speak for itself.  But it should be
recorded somewhere.  Maybe in the FAQ?

>> [...]
>
> Sounds good and sufficiently motivated to me.  I presume SCM_VECTORP,
> SCM_VECTOR_REF and SCM_VECTOR_SET will remain available as deprecated
> macros, won't they?

Yes, but their performance sucks.

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user