pika-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Pika-dev] Re: Guile FFI wrapper, t_scm_word ambiguity


From: Andreas Rottmann
Subject: [Pika-dev] Re: Guile FFI wrapper, t_scm_word ambiguity
Date: Sat, 31 Jan 2004 18:03:24 +0100
User-agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux)

Andreas Rottmann <address@hidden> writes:

> Hi!
>
> I just wanted to note that I have started a FFI wrapper for Guile,
> exposing the Pika FFI. I expect to have it ready so far that it can
> run eceval sometime next week.
>
I started the wrapper anew, since I realized it would probably make
sense to plug Guile in as just another "rep", i.e. leaving libscm/
mostly intact an modifying the stuff in reps/ to be just a thin layer
above Guile.

So far, with a bit of preprocessor magic, this seems work really
well. However, since in libscm/words.h I have

typedef SCM t_scm_word;

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. 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).

Cheers, 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

Python is executable pseudocode, Perl is executable line-noise.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]