* Guile API for foreign languages: proposing SCM scm_list_0(void) @ 2012-07-02 11:11 Alexei Matveev 2013-01-12 15:16 ` Andy Wingo 0 siblings, 1 reply; 12+ messages in thread From: Alexei Matveev @ 2012-07-02 11:11 UTC (permalink / raw) To: guile-devel, guile-user Quote from http://lists.gnu.org/archive/html/guile-devel/2001-06/msg00348.html >> Do we want scm_list_0 to scm_list_9 anyway? > > I'd say, forget about scm_list_0. With respect to the others, we should > at least provide those which are used in libguile (egoistic point of > view, isn't it?). About the rest up to 9 I don't know/mind. Hi, All, To raise this question again: I ended up with a wrapper function for a Fortran project equivalent to the scm_list_0() quoted below. The reason is accessing macros from languages other than C is cumbersome. Contrary to scm_from/to_int, scm_is_* and other macros adding this as a funciton one is a no-brainer, since it would be a new API call and raises no compatibility concerns. What do you think? Do you count from 0 or from 1? Alexei P.S.: the next on my which list would be scm_undefined(). $ git diff libguile/list.c diff --git a/libguile/list.c b/libguile/list.c index 8297b17..e253510 100644 --- a/libguile/list.c +++ b/libguile/list.c @@ -41,6 +41,12 @@ } while (0) SCM +scm_list_0 () +{ + return SCM_EOL; /* macro */ +} + +SCM scm_list_1 (SCM e1) { SCM c1; ^ permalink raw reply related [flat|nested] 12+ messages in thread
* Re: Guile API for foreign languages: proposing SCM scm_list_0(void) 2012-07-02 11:11 Guile API for foreign languages: proposing SCM scm_list_0(void) Alexei Matveev @ 2013-01-12 15:16 ` Andy Wingo 2013-01-14 22:44 ` Alexei Matveev 2013-01-22 10:55 ` Andy Wingo 0 siblings, 2 replies; 12+ messages in thread From: Andy Wingo @ 2013-01-12 15:16 UTC (permalink / raw) To: Alexei Matveev; +Cc: guile-user, guile-devel Hi Alexei, On Mon 02 Jul 2012 13:11, Alexei Matveev <alexei.matveev@gmail.com> writes: > To raise this question again: I ended up with a wrapper > function for a Fortran project equivalent to the scm_list_0() > quoted below. The reason is accessing macros from languages > other than C is cumbersome. > > Contrary to scm_from/to_int, scm_is_* and other macros > adding this as a funciton one is a no-brainer, since it would > be a new API call and raises no compatibility concerns. Apologies for ignoring you. I think that the thought that if we wanted to follow through the logic of making Guile's C API available to non-C languages, we should do so either all the way or not at all. Each additional function added to Guile's ABI imposes additional cost in runtime memory, ELF symbol resolution, and (to a degree) startup time, without providing any benefits to C users. On the other hand, if we are only talking about 2 functions (say), then clearly we should do it. So part of the question is, how much work are we talking about? I grepped the header files for lines starting with "#define SCM_", munged out the name of the macro and sorted them for uniqueness. That was around 1200 macros. I filtered out certain kinds of macros: * those ending in _H (header guards) * those starting with SCM_I_ (internal macros) * those containing _BIT (implementation details) * SCM_VALIDATE_ macros (there are corresponding C procedures) That left me with about 900 macros. I then filtered out all macros that had a corresponding C binding. For example, SCM_CAR has a C procedure, `scm_car'. That left me with about 780 macros. Finally, from this list, I filtered out those symbols that did not appear in our documentation. That resulted in the following 77 symbols: SCM_ALLOW_INTS SCM_ARG1 SCM_ARG2 SCM_ARG3 SCM_ARG4 SCM_ARG5 SCM_ARG6 SCM_ARG7 SCM_ARGn SCM_ASSERT_TYPE SCM_BOOL_F SCM_BOOL_T SCM_BYTEVECTOR_CONTENTS SCM_CELL_OBJECT SCM_CELL_OBJECT_0 SCM_CELL_OBJECT_1 SCM_CELL_TYPE SCM_CELL_WORD SCM_CELL_WORD_0 SCM_CELL_WORD_1 SCM_DEFER_INTS SCM_ELISP_NIL SCM_EOF_VAL SCM_EOL SCM_FRAME_DATA_ADDRESS SCM_FRAME_LOWER_ADDRESS SCM_FRAME_UPPER_ADDRESS SCM_GLOBAL_KEYWORD SCM_GLOBAL_VARIABLE SCM_GLOBAL_VARIABLE_INIT SCM_GPROC SCM_HOOKP SCM_IMP SCM_NEWSMOB SCM_NEWSMOB2 SCM_NEWSMOB3 SCM_PTAB_ENTRY SCM_PTOBNUM SCM_REGISTER_PROC SCM_RETURN_NEWSMOB SCM_RETURN_NEWSMOB2 SCM_RETURN_NEWSMOB3 SCM_SET_CELL_OBJECT SCM_SET_CELL_OBJECT_0 SCM_SET_CELL_OBJECT_1 SCM_SET_CELL_TYPE SCM_SET_CELL_WORD SCM_SET_CELL_WORD_0 SCM_SET_CELL_WORD_1 SCM_SET_SMOB_DATA SCM_SET_SMOB_DATA_2 SCM_SET_SMOB_DATA_3 SCM_SET_SMOB_FLAGS SCM_SET_SMOB_OBJECT SCM_SET_SMOB_OBJECT_2 SCM_SET_SMOB_OBJECT_3 SCM_SIMPLE_VECTOR_LENGTH SCM_SIMPLE_VECTOR_REF SCM_SIMPLE_VECTOR_SET SCM_SMOB_DATA SCM_SMOB_DATA_2 SCM_SMOB_DATA_3 SCM_SMOB_FLAGS SCM_SMOB_OBJECT SCM_SMOB_OBJECT_2 SCM_SMOB_OBJECT_2_LOC SCM_SMOB_OBJECT_3 SCM_SMOB_OBJECT_3_LOC SCM_SMOB_OBJECT_LOC SCM_SMOB_PREDICATE SCM_TICK SCM_UNBNDP SCM_UNBOUND SCM_UNDEFINED SCM_UNSPECIFIED SCM_VARIABLE_INIT The next step would be to manually check which of these symbols are actually necessary. Perhaps I can leave this job to someone else :) Regards, Andy -- http://wingolog.org/ ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Guile API for foreign languages: proposing SCM scm_list_0(void) 2013-01-12 15:16 ` Andy Wingo @ 2013-01-14 22:44 ` Alexei Matveev 2013-01-15 9:06 ` Andy Wingo 2013-01-22 10:55 ` Andy Wingo 1 sibling, 1 reply; 12+ messages in thread From: Alexei Matveev @ 2013-01-14 22:44 UTC (permalink / raw) To: guile-devel, guile-user >> The reason is accessing macros from languages >> other than C is cumbersome. > > Apologies for ignoring you. Hi, Wingo, Hi, All, No need to apologise, given your track record I trust you spending every minute of your time for a good purpose. :) Lack of time is a good evolutionary filter against worthless proposals. > I think that the thought that if we wanted > to follow through the logic of making Guile's C API available to non-C > languages, we should do so either all the way or not at all. This does not need to be a full Guile API, but rather a "Scheme" API --- the necessary minimum to "write Scheme in a foreign language". A language may be assumed to be C-interoperable, though macros should not be part of this interoperability. > Each additional function added to Guile's ABI imposes additional cost in > runtime memory, ELF symbol resolution, and (to a degree) startup time, > without providing any benefits to C users. On the other hand, if we are > only talking about 2 functions (say), then clearly we should do it. So > part of the question is, how much work are we talking about? Another valid reason to distinguish Guile and "Scheme" APIs. > I grepped the header files for lines starting with "#define SCM_", > munged out the name of the macro and sorted them for uniqueness. That > was around 1200 macros. I filtered out certain kinds of macros: > > * those ending in _H (header guards) > * those starting with SCM_I_ (internal macros) > * those containing _BIT (implementation details) > * SCM_VALIDATE_ macros (there are corresponding C procedures) > > That left me with about 900 macros. > > I then filtered out all macros that had a corresponding C binding. For > example, SCM_CAR has a C procedure, `scm_car'. That left me with about > 780 macros. > > Finally, from this list, I filtered out those symbols that did not > appear in our documentation. That resulted in the following 77 symbols: Thanks for a serious analysis. However there appear also to be some lower case scm_* macros documented as an API. Here are those that I had to "add to API as functions" in my case: scm_to_int(); scm_is_true(); scm_is_symbol(); scm_is_null(); These may be the real showstoppers. Someone on the list (or IRC) told me adding them as functions may result in a problem. Or was that "redefining them as functions"? I must confess that I never compiled Guile myself, so I am in no way qualified ehough to classify all the SCM_* macros left after your filtering, but let me start. The first group of a few constants contains those that are mentioned in the Scheme standard. Most of them may be obtained as a return value by calling that or another function. A global (linker) symbol or a dedicated "constructor" may be more convinient in some situations for foreign bindings: SCM_BOOL_F #f SCM_BOOL_T #t SCM_EOL '() SCM_UNDEFINED "something that when stored in a location makes it an error to try to obtain the value stored in the location (no such expression is defined in Scheme)" SCM_UNSPECIFIED (if #f #f) SCM_EOF_VAL (with-input-from-string "" read) Not so sure about the next two predicates. They do not have a Scheme counterpart, but appear to be an important implementation detail for functions of variable arity (I guess). There appears to be already some redundancy/confusion, at least for me [1]: SCM_UNBNDP SCM_UNBOUND The rest below should not be required to "write scheme in a foreign language", but rather to extend Scheme. Other macros, such as SCM_GLOBAL_VARIABLE_INIT, and snarfing magic are convenience macros for C programs and do not necessarily need to have a counterpart in other bindings: SCM_ALLOW_INTS SCM_ARG1 SCM_ARG2 SCM_ARG3 SCM_ARG4 SCM_ARG5 SCM_ARG6 SCM_ARG7 SCM_ARGn SCM_ASSERT_TYPE SCM_BYTEVECTOR_CONTENTS SCM_CELL_OBJECT SCM_CELL_OBJECT_0 SCM_CELL_OBJECT_1 SCM_CELL_TYPE SCM_CELL_WORD SCM_CELL_WORD_0 SCM_CELL_WORD_1 SCM_DEFER_INTS SCM_ELISP_NIL SCM_FRAME_DATA_ADDRESS SCM_FRAME_LOWER_ADDRESS SCM_FRAME_UPPER_ADDRESS SCM_GLOBAL_KEYWORD SCM_GLOBAL_VARIABLE SCM_GLOBAL_VARIABLE_INIT SCM_GPROC SCM_HOOKP SCM_IMP SCM_NEWSMOB SCM_NEWSMOB2 SCM_NEWSMOB3 SCM_PTAB_ENTRY SCM_PTOBNUM SCM_REGISTER_PROC SCM_RETURN_NEWSMOB SCM_RETURN_NEWSMOB2 SCM_RETURN_NEWSMOB3 SCM_SET_CELL_OBJECT SCM_SET_CELL_OBJECT_0 SCM_SET_CELL_OBJECT_1 SCM_SET_CELL_TYPE SCM_SET_CELL_WORD SCM_SET_CELL_WORD_0 SCM_SET_CELL_WORD_1 SCM_SET_SMOB_DATA SCM_SET_SMOB_DATA_2 SCM_SET_SMOB_DATA_3 SCM_SET_SMOB_FLAGS SCM_SET_SMOB_OBJECT SCM_SET_SMOB_OBJECT_2 SCM_SET_SMOB_OBJECT_3 SCM_SIMPLE_VECTOR_LENGTH SCM_SIMPLE_VECTOR_REF SCM_SIMPLE_VECTOR_SET SCM_SMOB_DATA SCM_SMOB_DATA_2 SCM_SMOB_DATA_3 SCM_SMOB_FLAGS SCM_SMOB_OBJECT SCM_SMOB_OBJECT_2 SCM_SMOB_OBJECT_2_LOC SCM_SMOB_OBJECT_3 SCM_SMOB_OBJECT_3_LOC SCM_SMOB_OBJECT_LOC SCM_SMOB_PREDICATE SCM_TICK SCM_VARIABLE_INIT Alexei [1] http://www.sourceware.org/ml/guile/2000-03/msg00618.html ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Guile API for foreign languages: proposing SCM scm_list_0(void) 2013-01-14 22:44 ` Alexei Matveev @ 2013-01-15 9:06 ` Andy Wingo 2013-01-15 9:20 ` Ludovic Courtès 0 siblings, 1 reply; 12+ messages in thread From: Andy Wingo @ 2013-01-15 9:06 UTC (permalink / raw) To: Alexei Matveev; +Cc: guile-user, guile-devel On Mon 14 Jan 2013 23:44, Alexei Matveev <alexei.matveev@gmail.com> writes: > scm_to_int(); > scm_is_true(); > scm_is_symbol(); > scm_is_null(); We can change these to inline functions, no problem. They would also get an out-of-line version written to the .so, so that should work for you too. It seems that we can indeed make all of our API available to non-C users. Any objections to doing so? Andy -- http://wingolog.org/ ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Guile API for foreign languages: proposing SCM scm_list_0(void) 2013-01-15 9:06 ` Andy Wingo @ 2013-01-15 9:20 ` Ludovic Courtès 0 siblings, 0 replies; 12+ messages in thread From: Ludovic Courtès @ 2013-01-15 9:20 UTC (permalink / raw) To: guile-devel; +Cc: guile-user Hi! Andy Wingo <wingo@pobox.com> skribis: > On Mon 14 Jan 2013 23:44, Alexei Matveev <alexei.matveev@gmail.com> writes: > >> scm_to_int(); >> scm_is_true(); >> scm_is_symbol(); >> scm_is_null(); > > We can change these to inline functions, no problem. They would also > get an out-of-line version written to the .so, so that should work for > you too. > > It seems that we can indeed make all of our API available to non-C > users. Any objections to doing so? You wrote: > Each additional function added to Guile's ABI imposes additional cost in > runtime memory, ELF symbol resolution, and (to a degree) startup time, > without providing any benefits to C users. On the other hand, if we are > only talking about 2 functions (say), then clearly we should do it. So > part of the question is, how much work are we talking about? So I agree: if we’re talking about a few functions, that’s fine; otherwise, that may be questionable. WDYT? Thanks, Ludo’. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Guile API for foreign languages: proposing SCM scm_list_0(void) 2013-01-12 15:16 ` Andy Wingo 2013-01-14 22:44 ` Alexei Matveev @ 2013-01-22 10:55 ` Andy Wingo 2013-01-31 11:27 ` Andy Wingo 1 sibling, 1 reply; 12+ messages in thread From: Andy Wingo @ 2013-01-22 10:55 UTC (permalink / raw) To: Alexei Matveev; +Cc: guile-devel [trimming out guile-user] For me, here is the list of symbols with no C counterpart, followed by a commented list of all of them. Symbols that a non-C program would need to interact with Guile: SCM_BOOL_F SCM_BOOL_T SCM_ELISP_NIL SCM_EOF_VAL SCM_EOL SCM_UNBOUND SCM_UNDEFINED SCM_UNSPECIFIED Any ideas on how we should expose these? Andy Specific comments: On Sat 12 Jan 2013 16:16, Andy Wingo <wingo@pobox.com> writes: > SCM_ALLOW_INTS > SCM_DEFER_INTS These have scm_dynwind_block_asyncs() and related. I removed the one place in the docs where they were erroneously mentioned. > SCM_ARG1 > SCM_ARG2 > SCM_ARG3 > SCM_ARG4 > SCM_ARG5 > SCM_ARG6 > SCM_ARG7 > SCM_ARGn Not needed; these are just the numbers 1 through 7 and 0. See "Handling Errors" in the manual. > SCM_ASSERT_TYPE There is scm_wrong_type_arg and scm_wrong_type_arg_msg > SCM_BOOL_F > SCM_BOOL_T These are needed I guess? > SCM_BYTEVECTOR_CONTENTS Probably we need scm_c_bytevector_contents() or so > SCM_CELL_OBJECT > SCM_CELL_OBJECT_0 > SCM_CELL_OBJECT_1 > SCM_CELL_TYPE > SCM_CELL_WORD > SCM_CELL_WORD_0 > SCM_CELL_WORD_1 > SCM_SET_CELL_OBJECT > SCM_SET_CELL_OBJECT_0 > SCM_SET_CELL_OBJECT_1 > SCM_SET_CELL_TYPE > SCM_SET_CELL_WORD > SCM_SET_CELL_WORD_0 > SCM_SET_CELL_WORD_1 > SCM_SET_SMOB_DATA > SCM_SET_SMOB_DATA_2 > SCM_SET_SMOB_DATA_3 > SCM_SET_SMOB_FLAGS > SCM_SET_SMOB_OBJECT > SCM_SET_SMOB_OBJECT_2 > SCM_SET_SMOB_OBJECT_3 > SCM_SMOB_DATA > SCM_SMOB_DATA_2 > SCM_SMOB_DATA_3 > SCM_SMOB_FLAGS > SCM_SMOB_OBJECT > SCM_SMOB_OBJECT_2 > SCM_SMOB_OBJECT_2_LOC > SCM_SMOB_OBJECT_3 > SCM_SMOB_OBJECT_3_LOC > SCM_SMOB_OBJECT_LOC Humm, I don't know. I would rather not expose these to other languages. > SCM_ELISP_NIL > SCM_EOF_VAL > SCM_EOL These are needed, too. > SCM_FRAME_DATA_ADDRESS > SCM_FRAME_LOWER_ADDRESS > SCM_FRAME_UPPER_ADDRESS Not these. > SCM_GLOBAL_KEYWORD > SCM_GLOBAL_VARIABLE > SCM_GLOBAL_VARIABLE_INIT > SCM_REGISTER_PROC > SCM_VARIABLE_INIT These are snarfing-related and unneeded. > SCM_GPROC > SCM_HOOKP Not these, I don't think. > SCM_IMP Not this one, hopefully. > SCM_NEWSMOB > SCM_NEWSMOB2 > SCM_NEWSMOB3 > SCM_RETURN_NEWSMOB > SCM_RETURN_NEWSMOB2 > SCM_RETURN_NEWSMOB3 There is scm_new_smob and scm_new_double_smob. I have changed the documentation to recommend them instead. > SCM_PTAB_ENTRY > SCM_PTOBNUM Not these. > SCM_SIMPLE_VECTOR_LENGTH > SCM_SIMPLE_VECTOR_REF > SCM_SIMPLE_VECTOR_SET Adequately handled by scm_c_vector interface > SCM_SMOB_PREDICATE I don't know. > SCM_TICK You can run scm_async_click instead; though I guess it should be called scm_async_tick. > SCM_UNBNDP A comparison to SCM_UNDEFINED is sufficient. > SCM_UNBOUND > SCM_UNDEFINED > SCM_UNSPECIFIED Needed. -- http://wingolog.org/ ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Guile API for foreign languages: proposing SCM scm_list_0(void) 2013-01-22 10:55 ` Andy Wingo @ 2013-01-31 11:27 ` Andy Wingo 2013-01-31 11:45 ` Andy Wingo 0 siblings, 1 reply; 12+ messages in thread From: Andy Wingo @ 2013-01-31 11:27 UTC (permalink / raw) To: Alexei Matveev; +Cc: guile-devel On Tue 22 Jan 2013 11:55, Andy Wingo <wingo@pobox.com> writes: > [trimming out guile-user] > > For me, here is the list of symbols with no C counterpart, followed by a > commented list of all of them. > > Symbols that a non-C program would need to interact with Guile: > > SCM_BOOL_F > SCM_BOOL_T > SCM_ELISP_NIL > SCM_EOF_VAL > SCM_EOL > SCM_UNBOUND > SCM_UNDEFINED > SCM_UNSPECIFIED > > Any ideas on how we should expose these? I propose that we don't expose them via functions; that seems silly to me. Instead, users should just keep a table of what the values of these constants are for a given Guile major series. Defining them as enumerated values doesn't help e.g. an Ada compiler. The particular language should make this list in their own source code format, perhaps generated by a small C program linked to libguile. Thoughts? Andy -- http://wingolog.org/ ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Guile API for foreign languages: proposing SCM scm_list_0(void) 2013-01-31 11:27 ` Andy Wingo @ 2013-01-31 11:45 ` Andy Wingo 2013-01-31 13:37 ` Noah Lavine ` (2 more replies) 0 siblings, 3 replies; 12+ messages in thread From: Andy Wingo @ 2013-01-31 11:45 UTC (permalink / raw) To: Alexei Matveev; +Cc: guile-devel On Thu 31 Jan 2013 12:27, Andy Wingo <wingo@pobox.com> writes: > On Tue 22 Jan 2013 11:55, Andy Wingo <wingo@pobox.com> writes: > >> SCM_BOOL_F >> SCM_BOOL_T >> SCM_ELISP_NIL >> SCM_EOF_VAL >> SCM_EOL >> SCM_UNBOUND >> SCM_UNDEFINED >> SCM_UNSPECIFIED >> > Instead, users should just keep a table of what the values of these > constants are for a given Guile major series. Defining them as > enumerated values doesn't help e.g. an Ada compiler. The particular > language should make this list in their own source code format, perhaps > generated by a small C program linked to libguile. Or by Scheme: (for-each (lambda (pair) (format #t "static const scm_t_bits my_~A = 0x~X;\n" (car pair) (object-address (cdr pair)))) `(("false" . #f) ("true" . #t) ("nil" . #nil) ("eof" . ,the-eof-object) ("eol" . ()) ("unspecified" . ,*unspecified*))) static const scm_t_bits my_false = 0x4; static const scm_t_bits my_true = 0x404; static const scm_t_bits my_nil = 0x104; static const scm_t_bits my_eof = 0xa04; static const scm_t_bits my_eol = 0x304; static const scm_t_bits my_unspecified = 0x804; Unbound and undefined are a little trickier. Andy -- http://wingolog.org/ ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Guile API for foreign languages: proposing SCM scm_list_0(void) 2013-01-31 11:45 ` Andy Wingo @ 2013-01-31 13:37 ` Noah Lavine 2013-01-31 14:13 ` Alexei Matveev 2013-01-31 16:57 ` Alexei Matveev 2 siblings, 0 replies; 12+ messages in thread From: Noah Lavine @ 2013-01-31 13:37 UTC (permalink / raw) To: Andy Wingo; +Cc: guile-devel, Alexei Matveev [-- Attachment #1: Type: text/plain, Size: 1654 bytes --] I don't know much about language interfaces, but why not have these be constants exported by libguile.so? Is there any reason for other languages to have to make their own lists? Thanks, Noah On Thu, Jan 31, 2013 at 6:45 AM, Andy Wingo <wingo@pobox.com> wrote: > On Thu 31 Jan 2013 12:27, Andy Wingo <wingo@pobox.com> writes: > > > On Tue 22 Jan 2013 11:55, Andy Wingo <wingo@pobox.com> writes: > > > >> SCM_BOOL_F > >> SCM_BOOL_T > >> SCM_ELISP_NIL > >> SCM_EOF_VAL > >> SCM_EOL > >> SCM_UNBOUND > >> SCM_UNDEFINED > >> SCM_UNSPECIFIED > >> > > Instead, users should just keep a table of what the values of these > > constants are for a given Guile major series. Defining them as > > enumerated values doesn't help e.g. an Ada compiler. The particular > > language should make this list in their own source code format, perhaps > > generated by a small C program linked to libguile. > > Or by Scheme: > > (for-each > (lambda (pair) > (format #t "static const scm_t_bits my_~A = 0x~X;\n" > (car pair) (object-address (cdr pair)))) > `(("false" . #f) > ("true" . #t) > ("nil" . #nil) > ("eof" . ,the-eof-object) > ("eol" . ()) > ("unspecified" . ,*unspecified*))) > > static const scm_t_bits my_false = 0x4; > static const scm_t_bits my_true = 0x404; > static const scm_t_bits my_nil = 0x104; > static const scm_t_bits my_eof = 0xa04; > static const scm_t_bits my_eol = 0x304; > static const scm_t_bits my_unspecified = 0x804; > > Unbound and undefined are a little trickier. > > Andy > -- > http://wingolog.org/ > > [-- Attachment #2: Type: text/html, Size: 2572 bytes --] ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Guile API for foreign languages: proposing SCM scm_list_0(void) 2013-01-31 11:45 ` Andy Wingo 2013-01-31 13:37 ` Noah Lavine @ 2013-01-31 14:13 ` Alexei Matveev 2013-01-31 16:57 ` Alexei Matveev 2 siblings, 0 replies; 12+ messages in thread From: Alexei Matveev @ 2013-01-31 14:13 UTC (permalink / raw) To: guile-devel > static const scm_t_bits my_false = 0x4; > static const scm_t_bits my_true = 0x404; > static const scm_t_bits my_nil = 0x104; > static const scm_t_bits my_eof = 0xa04; > static const scm_t_bits my_eol = 0x304; > static const scm_t_bits my_unspecified = 0x804; I see it is not common to export constants to libguile, here a complete list of read-only symbols in the version 1.8: $ nm /usr/lib/libguile.a | grep " R " 00000040 R scm_charnames 00000000 R scm_charnums 00000060 R scm_s_bindings 0000006d R scm_s_body 0000003c R scm_s_clauses 0000007f R scm_s_expression 00000030 R scm_s_formals 00000076 R scm_s_test 00000053 R scm_s_variable There must be a practical reason for it. This could be the same reason which made me come up with a function that returns dearly missing SCM_EOL and not a global variable for use in a Fortran project. For comparison the text section exports 2K functions: $ nm /usr/lib/libguile.a | grep " T " | wc 2152 6456 63620 Compile-time constants are cumbersome. In C there is only #define and every other language handles them slightly differently, yet other do not have a "compilation phase" at all. It is hopeless to come up with a language-agnostic solution for the compile-time constants. This optimization should be ideed left to the language. However, if Guile API declares them to compile time constants and this work will need to be done once for every API version. Alexei ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Guile API for foreign languages: proposing SCM scm_list_0(void) 2013-01-31 11:45 ` Andy Wingo 2013-01-31 13:37 ` Noah Lavine 2013-01-31 14:13 ` Alexei Matveev @ 2013-01-31 16:57 ` Alexei Matveev 2013-01-31 17:23 ` Andy Wingo 2 siblings, 1 reply; 12+ messages in thread From: Alexei Matveev @ 2013-01-31 16:57 UTC (permalink / raw) To: Andy Wingo; +Cc: guile-devel > static const scm_t_bits my_false = 0x4; > static const scm_t_bits my_true = 0x404; > static const scm_t_bits my_nil = 0x104; > static const scm_t_bits my_eof = 0xa04; > static const scm_t_bits my_eol = 0x304; > static const scm_t_bits my_unspecified = 0x804; I get slightly different values for 1.8 (32 bit x86), here in Fortran syntax: type, public, bind(c) :: scm_t private integer(c_intptr_t) :: ptr end type scm_t type(scm_t), public, parameter :: my_false = scm_t (x'004') type(scm_t), public, parameter :: my_true = scm_t (x'104') type(scm_t), public, parameter :: my_eof = scm_t (x'304') type(scm_t), public, parameter :: my_eol = scm_t (x'404') type(scm_t), public, parameter :: my_unspecified = scm_t (x'504') Do I assume correctly that #nil does not exist in 1.8? So at the moment when everybody migrates to 2.0 that would mean an #ifdef/esle/endif with two sets of compile time constants. So far I was able to avoid that. Though in this way one can make them true compile-time "parameters". Are these numbers likely to change between 32/64 bit architectures? I used this slightly modified code to get those numbers: (define (const-dump) (for-each (lambda (pair) (format #t "static const scm_t_bits my_~A = 0x~X;\n" (car pair) (object-address (cdr pair)))) `(("false" . #f) ("true" . #t) ;; ("nil" . #nil) ("eof" . ,(with-input-from-string "" read)) ("eol" . ()) ("unspecified" . ,(if #f #f))))) Alexei ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Guile API for foreign languages: proposing SCM scm_list_0(void) 2013-01-31 16:57 ` Alexei Matveev @ 2013-01-31 17:23 ` Andy Wingo 0 siblings, 0 replies; 12+ messages in thread From: Andy Wingo @ 2013-01-31 17:23 UTC (permalink / raw) To: Alexei Matveev; +Cc: guile-devel On Thu 31 Jan 2013 17:57, Alexei Matveev <alexei.matveev@gmail.com> writes: >> static const scm_t_bits my_false = 0x4; >> static const scm_t_bits my_true = 0x404; >> static const scm_t_bits my_nil = 0x104; >> static const scm_t_bits my_eof = 0xa04; >> static const scm_t_bits my_eol = 0x304; >> static const scm_t_bits my_unspecified = 0x804; > > I get slightly different values for 1.8 (32 bit x86) Yes, it is possible to have different values for these. They are part of the ABI, not the API. As such, the values of these constants are the same throughout one stable release series. So they have one set of values for 1.8, another for 2.0, another for 2.2, etc. In theory they are architecture-dependent but in practice they are the same on all architectures, 32-bit or 64-bit, ARM or x86, etc. > I used this slightly modified code to get those numbers: Go ahead and generate Fortran code, I would say :) No sense in bothering to generate C. Cheers, Andy -- http://wingolog.org/ ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2013-01-31 17:23 UTC | newest] Thread overview: 12+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2012-07-02 11:11 Guile API for foreign languages: proposing SCM scm_list_0(void) Alexei Matveev 2013-01-12 15:16 ` Andy Wingo 2013-01-14 22:44 ` Alexei Matveev 2013-01-15 9:06 ` Andy Wingo 2013-01-15 9:20 ` Ludovic Courtès 2013-01-22 10:55 ` Andy Wingo 2013-01-31 11:27 ` Andy Wingo 2013-01-31 11:45 ` Andy Wingo 2013-01-31 13:37 ` Noah Lavine 2013-01-31 14:13 ` Alexei Matveev 2013-01-31 16:57 ` Alexei Matveev 2013-01-31 17:23 ` Andy Wingo
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).