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] |
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
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |