* 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; 5+ 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] 5+ 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 0 siblings, 1 reply; 5+ 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] 5+ 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 0 siblings, 1 reply; 5+ 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] 5+ 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; 5+ 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] 5+ 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; 5+ 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] 5+ messages in thread
end of thread, other threads:[~2013-01-15 9:20 UTC | newest] Thread overview: 5+ 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
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).