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

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

[Alexei Matveev]

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;

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

[Andy Wingo]

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/

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

[Alexei Matveev]

>> 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

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

[Andy Wingo]

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/

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

[Ludovic Courtès]

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’.

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

[Andy Wingo]

[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/

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

[Andy Wingo]

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/

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

[Andy Wingo]

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/

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

[Noah Lavine]

[-- 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 --]

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

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 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

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

[Andy Wingo]

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/