* 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).