Re: Suggestion: new snarf macro set

[Dirk Herrmann <dirk at ida dot ing dot tu-bs dot de>]

On 16 May 2000, Keisuke Nishida wrote:

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

> SCM_GPROC1            -> SCM_DEFINE_GENERIC_R_PREDICATE (for scm_tc7_rpsubr)

same

>                       -> SCM_DEFINE_GENERIC_C_FUNCALL (for scm_tc7_cxr)

Hmmm.  I'm not sure about that name.  Sorry, no better idea at the moment
yet.  I will think about it.

> 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.  And:  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).  Also, maybe STATIC
instead of LOCAL would be better, but that's a matter of taste, obviously.

> New macros:
> 
> SCM_C_VARIABLE        Similar to SCM_DEFINE_VARIABLE but available only in C.
> SCM_C_LOCAL_VARABLE   Ditto but local.

Same:  I suggest to use SCM_DEFINE_C_XXX

> Primitive macros:
> 
> SCM_HERE              -> SCM_SNARF_HERE
> SCM_INIT              -> SCM_SNARF_INIT
> SCM_DOCS              -> SCM_SNARF_DOCS

Hmm... So the rule is:  Helper macros for the snarfer are named
SCM_SNARF_XXX?  Sounds good to me.


Summary:  I very much appreciate your suggestion.  I just would go
even further with respect to naming consistency.

> I can work on this change if permitted.  I can also write elisp commands
> that help people insert these macros.  Old macros may be moved to a new
> file compat.h or obsolete.h all together.  

I think the current snarfer macros were introduced after the last
release?  If that is true, then we would not need to keep them for
compatibility reasons.  The idea with the elisp commands is also very
cool, btw.

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.

Thank you very much!
Dirk