This is the mail archive of the guile@sourceware.cygnus.com mailing list for the Guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Names in libguile


On 18 Mar 2000, Mikael Djurfeldt wrote:

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

However, maybe we should then have an additional prefix for libguile
functions that are neither a primitive nor a c-level convenience variant
of a primitive.  The problem is the following:  If we allow to have some
function be simply be named 'scm_foo', then nobody can extend guile with a
primitive 'foo' any more without violating the naming scheme.  Names
from the C level in libguile thus 'reflect' somehow back into the scheme
level namespace.  If, instead, we would say that we use for example scm_l_
(for library or whatever) to indicate such functions, this does not
pollute the scheme level namespace or force naming scheme violations.

Thinking more about it, maybe we should do it the other way around?  In
fact, reserving prefixes like scm_l_, scm_sym_, scm_i_ and more already do
indirectly pollute the scheme level namespace!  How do we call a
primitive for 'c-code-parser'?  'scm_c_code_parser'?  Ooops!  If, in
contrast, we would say that primitives are named, say, scm_p_, then this
does not at all influence the scheme level.  If a scheme function is
called (p-foo), then this gives simply scm_p_p_foo, and everything is
consistent!

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

I agree with you that code should be pretty and easy to read.  However,
maybe I am the only one that from time to time stumbles across a guile
macro SCM_XXXP and only at second thought realizes that this is a
predicate?  SCM_IMP is always a candidate for such a confusion.  SCM_INUMP
is another one.  I can't tell why especially these tend to fool me.

Further, when using the GNU coding convention to always put some space
between the macro and the opening paranthese, the following does not seem
much different with regard to readability.  It may be that with _P the
brain needs some small amount of additional time since it has to process
something (the _P) that looks like an additional word, but on the other
hand it more reliably gets the actual meaning.  (Again, this is obviously
my personal view and I don't want to be annoying about it.).

SCM_NULLP (something)                    SCM_NULL_P (something)
SCM_IMP (something)                      SCM_IM_P (something)
SCM_MARKEDP (something)                  SCM_MARKED_P (something)
SCM_REALP (something)                    SCM_REAL_P (something)

Best regards
Dirk Herrmann


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]