Re: SCM_CALL_N

[Dirk Herrmann]

On Tue, 26 Jun 2001, Keisuke Nishida wrote:

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

I think these names are OK.

Maybe we should also think of renaming scm_apply to scm_i_apply (or even
make it static in eval.c) and have one function scm_apply that can be
called from C and from scheme as one would expect it (well, would that be
like scm_apply_0 or scm_apply_1 above?).  The usual type checks could be
performed in scm_apply, thus (potentially) reducing the type checking
overhead in the current scm_apply.

> Should we name these functions scm_xxx_N or scm_xxxN?

scm_xxx_N, goes along with SCM_CELL_WORD_N and such.

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

In the long term, yes, because we could use inlining.  I don't think,
however, that we should actually replace the SCM_LIST_N macros now:  If we
deprecate the old SCM_LIST_N macros, we can't use them in guile itself any
more.  But, this will cause a performance degradation, since we can't make
use of inlining yet.  We could, however, _add_ the functions to the
interface.

Best regards,
Dirk Herrmann