Re: [Pika-dev] Guile FFI: resizable vector problem

[Tom Lord]

    > From: Andreas Rottmann <address@hidden>

    > The next thing I ran into: Guile has dropped resizable vectors some
    > time ago. A rationale can be found in [0]. The argument seems sound to
    > me, so what about Pika -- won't resizable vectors yield the same
    > problem wrt to threading? For now, I'll just work around that by
    > making scm_set_n_vector_elts() create a new vector.

(Jivera answered your questions about threads and the Pika vector
interface.)

Let's step back a second.   It'd be helpful to clarify your goals.

One goal might be described by the recipe:

* "infer" from the Pika API's a kind of "portable FFI"
  which _any_ Scheme implementation should be able to
  provide.   That is -- infer an alternative to the SRFI-50 
  draft.

* Implement that FFI for Guile.

* Use it to write modules for Guile with some degree of confidence
  that they'll be portable to Pika and hopefully to other
  implementations as well.


The other goal might be described by the recipe:

* Implement src/scm/reps using parts of Guile.   Parts of
  Guile's object representations.   Guile's GC.  Guile's
  fixnums and boxed doubles.   Guile's smobs as vtable objects.
  (etc.)

* Meanwhile we finish the rest of src/scm.

Then we wind up with multiple implementations of reps/ right off the
bat.  And those will make usefully different trade-offs, hopefully.

The thing about this second plan is that it means _not_ using all of
Guile and not being to mix all modules written using "native Guile"
APIs with Pika code.    For example, in Pika, vectors are (no matter
how reps/ is implemented) vtable objects.   So it's quite possibly
that the vector code from Guile just wouldn't be used.

That's not _absolutely_ true -- a Guile-based reps/ *could*
conceivably special-case vtable objects which it knows are vectors.
It might be able to use the Guile vector code directly, after all.
But if so, it would probably want to modify or augment the Guile code
-- for example to make vector_resize work.

(I actually like the second plan and had presumed that's what you
wanted to do -- but I also like the first plan.)

    > http://mail.gnu.org/archive/html/guile-devel/2000-10/msg00049.html

That message says it all:

    msg> And now to the problem: How do you use a vector?  You
    msg> typically extract the pointer to the elements and work on
    msg> those, while still making sure that the vector object is gc
    msg> protected.  But, if resizing of vectors is allowed, this
    msg> does not work anymore

It's a flaw of the Guile API (inherite from SCM) that the way you
usually work on a vector is to extract a pointer to the array of
elements.

That's just a swell paradigm for SCM but it was never really
appropriate for Guile, given the goal of being a general-purpose
extension language.

The Pika API doesn't work that way.  You never (other than
(optionally) in reps/) get "a pointer to the array of elements".   The
problem doesn't occur.

There will eventually be a need in the Pika API for calls that let you
"lock" a vector or two briefly, during which time it is promised that
they won't resized.   But that's mostly a separate topic.

-t