Re: Guile FFI wrapper, t_scm_word ambiguity
Andreas Rottmann <[email protected]> Sat, 31 Jan 2004 18:03:24 +0100
| Newsgroups | gmane.lisp.scheme.pika.devel |
|---|---|
| Message-ID | <[email protected]> |
Andreas Rottmann <[email protected]> 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 | [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 Python is executable pseudocode, Perl is executable line-noise.