Re: SCM_CALL_N

[Keisuke Nishida]

At 25 Jun 2001 17:01:17 -0500,
Rob Browning wrote:
> 
> > However, should we use macros for this or functions?  Functions would
> > make it easier to maintain backward compatibility and would stand out
> > as something special in the code.  But are we concerned about binary
> > compatibility yet?  Hmm, I don't think so.
> 
> I tend to think that unless there's a *really* good reason for making
> something a macro, we shouldn't.  So if performance isn't critical
> here (i.e. making it a function doesn't cost a lot relative to the
> overhead already involved), and if there's no other reason to make
> these macros, we shouldn't.
> 
> Also, if 99% of the compilers we're going to be using support inline
> in a sane manner, that would be preferable to macros for many cases as
> well IMO.

Probably right.  What about the following functinos?

  scm_call_0 (proc);
  scm_call_1 (proc, arg1);
  scm_call_2 (proc, arg1, arg2);
  scm_call_3 (proc, arg1, arg2, arg3);

  scm_apply_0 (proc, args);
  scm_apply_1 (proc, arg1, args);
  scm_apply_2 (proc, arg1, arg2, args);
  scm_apply_3 (proc, arg1, arg2, arg3, args);

Performance won't be critical because these functions call
scm_apply, which does cost a lot.  (Or we could optimize
the above functions by directly processing function calls.)

Should we name these functions scm_xxx_N or scm_xxxN?

Also, should we create a new functions scm_list_N, replacing
the existing macros SCM_LIST_N?

Keisuke