This is the mail archive of the
guile@sourceware.cygnus.com
mailing list for the Guile project.
Re: Names in libguile
- To: "Greg J. Badros" <gjb at cs dot washington dot edu>
- Subject: Re: Names in libguile
- From: Dirk Herrmann <dirk at ida dot ing dot tu-bs dot de>
- Date: Fri, 17 Mar 2000 19:05:57 +0100 (MET)
- cc: Mikael Djurfeldt <djurfeldt at nada dot kth dot se>, guile at sourceware dot cygnus dot com
On 17 Mar 2000, Greg J. Badros wrote:
> All of these notes should be summarized and stuck in a file in the
> guile-core module (and updated).
There are still some open points:
scm_c_XXX :
Only used for C-level variants of a scm_XXX schene primitive, or
rather to be used for everything that is not a scheme primitive?
scm_i_XXX :
Only for internal _functions_ or rather for everything that is
internal? For example, scm_sym_ is for symbols that may be used by
users, while scm_i_sym_ is used for guile internally? Otherwise we
can't distinguish between C variables holding symbols that are part of
the official API and internally used C variables holding symbols.
what about boolean variables/constants? scm_bool_? This would fit nicely
with the current macro names SCM_BOOL_T and SCM_BOOL_F.
what about number variables/constants? scm_num_? There is at least a
SCM_MAKINUM(0) somewhere...
scm_s_, scm_k_, scm_sym_, scm_var_:
What about macro variants of these? At least, some symbols and
constants are represented as macros.
Macros in general:
Should internally used macros be called SCM_I_xxx, thus following the
above scheme?
How do scheme-level names translate if there are macros that do the
same thing? set-car! --> SCM_SETCAR, thus, the '!' is dropped and the
intermediate '-' is dropped. However, this is not done
consistently: sometimes intermediate '-' are _not_ dropped.
Currently it seem that:
- becomes sometimes _ and sometimes nothing
! becomes nothing
? becomes P for single-word xxx, _P otherwise
% becomes I don't know what.
I would prefer if both worlds (functions/variables and macros) were using
similar schemes as far as possible. (I even dislike the _P/P
distinction, but I know that I am strange :-)
Best regards
Dirk Herrmann