Re: SCM_CALL_N

[Lars J. Aas]

On Tue, Jun 26, 2001 at 05:12:02PM +0200, Dirk Herrmann wrote:
: On Tue, 26 Jun 2001, Lars J. Aas wrote:
: > On Tue, Jun 26, 2001 at 01:46:33AM +0200, Marius Vollmer wrote:
: > : Additionally, what about
: > : 
: > :     scm_call_n (proc, n, ...);
: > :     scm_apply_n (proc, n, ...);
: > : 
: > : where the number of arguments is given explicitely.
: > 
: > I'm more fan of terminating the end of the arglist than counting the
: > args I've given and updating the count if I change something.  More
: > convenience - less efficience?  Both systems can be provided, of course.
: > 
: >   SCM scm_va_apply( proc, ... ); /* decl */
: > 
: >   scm_va_apply( proc, arg1, arg2, [...], SCM_EOL ); /* usage */
: 
: I agree with respect to your argument that using an explicit count is
: probably not a good idea.  However, I'd like to mention that we should not
: use SCM_EOL as a terminator, since SCM_EOL may be a valid argument.  
: Instead, SCM_UNDEFINED should be used to terminate the argument list,
: since it can never represent any legal object.

Good point about not using SCM_EOL.  Might be still better to use NULL
for terminator though, since it's the most common practice and ideal for
use as a C condition (NULL is FALSE, everything else is TRUE).

: And, another point, I
: prefer the scm_<foo>_n naming scheme over the scm_va_<foo> naming.  The
: varags implementation is something that should be hidden from the
: user.  Nobody ever wants to think about how printf is actually realized...

I've never minded that the vararg-nature of the functions vprintf() and
XtVaSetValues() was evident in the function name.  If you want to make it
possible to specify the number of args (if there's a performance gain in
having that info?) you will need different names for the functions.  To
me, _n may seem like a function where you specify the number of args, while
_va tells me I need to terminate the arglist.

BTW, *I* actually like thinking about how printf() is implemented :)

: > Another thing about varargs is that you should probably set up vararg
: > functions as mere wrappers for functions working on the va_list datatype.
: > If you don't, you can't wrap those functions because you can't expand the
: > va_list data into the ... positions.  At least I haven't figured out
: > how...
: 
: Hmmm.  I don't get it.  What is the problem?

Try making your own wrapper around printf() and see.  You can't - you can
only pretend you wrap printf() but actually forward the invokation to
vprintf().  That's probably why the vprintf() family is there - so you can
make your own variants that wrap the real printf-implementation.
It's a moot point since it's only a problem if you need to make wrapper
functions, and you may not want to invest any extra effort in libguile to
support that.

  Lars J
-- 
This is your life and it's ending one minute at a time.