Re: Names in libguile

[Mikael Djurfeldt <mdj at mdj dot nada dot kth dot se>]

Dirk Herrmann <dirk@ida.ing.tu-bs.de> writes:

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

I don't know.  To have it for all non-internal non-scheme functions
would perhaps be more consistent, but it is also more to type and may
make the code slightly less readable.

Maybe it is enough to have it for variants of a Scheme primitive.
It's kind of good that this makes you aware of the existence of the
Scheme version.

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

It might actually be a good idea to use scm_i_ for everything that
isn't meant to be part of the API.  One might argue that it is enough
to specify in the manual what is the API, but it is quite important
that people don't start to access things which was never meant to be
API.

> what about boolean variables/constants? scm_bool_?  This would fit nicely
>     with the current macro names SCM_BOOL_T and SCM_BOOL_F.

Actually, the convention we seem to have used, when there has been a
convention, is xxxp or xx_yy_p, that is the same as for predicates.
Example:

  pstate->writingp

> what about number variables/constants? scm_num_?  There is at least a
>     SCM_MAKINUM(0) somewhere...

There's no convention for this.  0 is SCM_INUM0.

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

Maybe this is a good idea if one wants to explicitly point out that
it's not part of the API.  (Do people think this is OK, or would the
code be too unreadable?)

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

The translation scheme is only valid for Scheme primitives.  Each
Scheme primitive corresponds to a C function which implements it.
I think we can handle other cases without policy.

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

Certainly _P is simpler, but then, Helvetica is simpler and more
consistent than Times Roman and the latter is much more readable in
the long run.

Code should be pretty and easy to read, not only simple and
consistent.  (Besides, the _P/P *is* 100% consistent, just a little
bit complex.)