Re: Re: Guile FFI wrapper, t_scm_word ambiguity

Matthew Dempsky <[email protected]> writes:

> 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.
>
Yes, I thought about that, but I hope Tom will choose #2 or #3.

> 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 *.
>
I'll just go on with approach #1 until some consens is reached.

> Seperating the uses of t_scm_word into integer and Pika value (choice
> #3) seems the cleanest solution to me at least.
>
That's my opinion, too.

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

Make free software, not war!