Re: Guile API for foreign languages: proposing SCM scm_list_0(void)

[Alexei Matveev]

>    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