Re: Suggestion: new snarf macro set

[Keisuke Nishida <kxn30 at po dot cwru dot edu>]

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

> > SCM_DEFINE1           -> SCM_DEFINE_R_PREDICATE (for scm_tc7_rpsubr)
> >                       -> SCM_DEFINE_ACCUMULATION (for scm_tc7_asubr)
> 
> I think it is a very cool idea to make the use of the different functions
> types more explicit.  Maybe we shouldn't use abbreviations, though.  What
> does the R stand for?  Recursive?  I think it's probably more in the
> direction of 'evaluating to the right' or something, right?

I guessed "rpsubr" stands for "relational predicate subroutine", but
SCM_DEFINE_GENERIC_RELATIONAL_PREDICATE is too long...  I don't know
any good one word that can be used here.

> > Rename without docstring:
> > 
> > SCM_REGISTER_PROC     -> SCM_MAKE_PROCEDURE_ALIAS
> > SCM_GLOBAL_SYMBOL     -> SCM_MAKE_SYMBOL
> > SCM_SYMBOL            -> SCM_MAKE_LOCAL_SYMBOL
> > SCM_GLOBAL_KEYWORD    -> SCM_MAKE_KEYWORD
> > SCM_KEYWORD           -> SCM_MAKE_LOCAL_KEYWORD
> 
> Why without docstring?  I'm very much in favor of being able to give
> docstrings to anything, especially for procedure aliases.

Probably true.  Aliases could have docstrings if there is a good reason
to do so (such as, "This procedure is obsolete; use xxx instead.").
However, I think writing docstrings for symbols and keywords is a little
but awkward.

> Why not use SCM_DEFINE_XXX here?  Maybe SCM_DEFINE_SYMBOL sounds a
> little bit weird, but is more consistent.  Macros that are named
> SCM_MAKE_ are typically to be used within code and not for top-level
> declarations.  In contrast, SCM_DEFINE_ as a prefix should be used for
> top-level declarations (at least that's my personal opinion).

SCM_MAKE_* create some objects rather than defining something, so I used
a different prefix.  But using SCM_DEFINE_ for all snarf macros is more
consistent for programmers, right.  I agree with that.

> Also, maybe STATIC instead of LOCAL would be better, but that's a
> matter of taste, obviously.

Yes.  By the way, do we really need the STATIC (or LOCAL) version?
It doesn't break user's name space anyway.

> Would you, after some other guilers have picked on my comments, provide an
> update, i. e. keep track of the issue?  I hope we get to a widely accepted
> solution soon!  This will help to improve the documentation efforts.

Sure.  I can't write actual docstrings, though :)

-- Kei