Re: Re: Guile FFI wrapper, t_scm_word ambiguity

Andreas Rottmann <[email protected]> writes:

> And SCM is supposed to be opaque (and happens to be implemented as
> pointer normally), I wondered if it wouldn't be appropriate to make
> t_scm_word an opaque type too. ATM, t_scm_word is used both to denote
> a "scheme value" and an unsigned integer (e.g. all the hash functions
> return a t_scm_word). I had to replace these uses of t_scm_word with
> t_ulong.

Ooh, I hadn't thought of that problem originally... (I think it's a
valid issue though.)

> So these options seem to exist:
>
> 1) Just s/t_scm_word/t_ulong/ where apropriate for the Guile Pika FFI,
>    as I've done now and leave everything the same in the "real" Pika.
>
> 2) The same as 1), but the do the substitutions in "real" Pika.
>
> 3) Add a new typedef that replaces the t_scm_word in the places where
>    it is used as plain integer.
>
> I'd favor 2) or 3), although I havne't yet been able to think of an
> appropriate name for 3).

I don't know how well it would work, but there's at least one more
alternative:

4) Leave t_scm_word as an unsigned long and cast to an SCM as
   appropriate in the Guile wrapper FFI.

That would at least leave the Guile/Pika FFI compatible with Pika's
until Tom can voice his thoughts.  In fact, it's really similar to how
Pika has scmx_pointer_value to cast a t_scm_word to a void *.

Seperating the uses of t_scm_word into integer and Pika value (choice
#3) seems the cleanest solution to me at least.  We have briefly
discussed on IRC the possibily of making a standard binary interface
for Pika libraries -- this would involve probably standardizing at
least that t_scm_words were the same size as an unsigned long or
something, but I think that's an issue can be orthogonal to this
problem.

-jivera