Hi Alexei, On Mon 02 Jul 2012 13:11, Alexei Matveev <alexei.matv...@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/