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

[Andreas Rottmann]

Tom Lord <address@hidden> writes:

>     > 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.
>
Yes, I already noticed that my wrapper will not end up using the Guile
reader/writer, but the one from libscm/.

> That's not _absolutely_ true -- a Guile-based reps/ *could*
> conceivably special-case vtable objects which it knows are vectors.
>
It does already (vtable-obj-imp.c):

struct scm_vtable *
scm_value_vtable (t_scm_arena arena, t_scm_word * value)
{
  /* FIXME: This could be faster */
  
  if (SCM_BOOLP (*value))
    return &scm_boolean_vtable;
[...]
  else if (SCM_VECTORP (*value))
    return &scm_vector_vtable;
  else
    {
      panic ("no vtable for type yet");
      return 0;
    }
}

> 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.
>
Yes, the current vector_resize code just allocates a new vector;
altough it would be quite simple to avoid that by going a bit deeper
into Guile internals and cook up a Guile vector resize primitive.

> (I actually like the second plan and had presumed that's what you
> wanted to do -- but I also like the first plan.)
>
I go more in the direction of the second plan, but I don't thing that
it contradicts the first.

>     > http://mail.gnu.org/archive/html/guile-devel/2000-10/msg00049.html
>
> 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.
>
Since this message is from 2000, things have changed a bit; the Guile
vector API using a base pointer (SCM_VELTS) has been augmented by
SCM_VECTOR_REF/SET, so I think there is no real obstacle in re-adding
resizable vectors to Guile itself (and deprecating SCM_VELTS at the
same time). I'll ask about that on guile-user or -dev, once I've come
up with code for that.

Andy
-- 
Andreas Rottmann         | address@hidden      | address@hidden | address@hidden
http://yi.org/rotty      | GnuPG Key: http://yi.org/rotty/gpg.asc
Fingerprint              | DFB4 4EB4 78A4 5EEE 6219  F228 F92F CFC5 01FD 5B62

Packages should build-depend on what they should build-depend.