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:

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

So why not just SCM_DEFINE_GENERIC_RELATION?  Should be sufficient and is
symmetric with the ACCUMULATION macros.

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

The problem is here, that SCM_DEFINE_ as a prefix leads to the assumption
that it is related to scheme's define, but the concept that we both have
in mind here is actually a mixture between scheme and C level
definitions.  That's a matter of documenting the macros, though.  (Or,
maybe, a reason to look for a better prefix than SCM_DEFINE, but I can't
think of anything more appropriate.  Native speakers?)

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

I think we do.  My personal opinion (which I think goes along with common
software engineering recommendations) is to keep scopes as small as
possible in order to minimize dependencies between different units.  As
became obvious when I wanted to eliminate some of the macros in numbers.h,
people tend to use things that are available, even if they are not part of
an official API.  (Don't want to pick on anybody here:  We all know that
Guile's official API has been quite vague for some time.)

Best regards
Dirk