guile-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: SCM_CALL_N


From: Dirk Herrmann
Subject: Re: SCM_CALL_N
Date: Tue, 26 Jun 2001 17:04:53 +0200 (MEST)

On Tue, 26 Jun 2001, Keisuke Nishida wrote:

> At Tue, 26 Jun 2001 09:24:51 +0200 (MEST),
> Dirk Herrmann wrote:
> > 
> > > 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.
> 
> At the present, the SCM_LIST_N macros use more than one scm_cons
> or scm_cons2.  We could instead allocate new cells directly in the
> new scm_list_N functions, which would cost no more than now.
> What about that?

Yes, you are right.  Sorry that I have not checked it before
replying.  With a proper implementation you could even get a better
performance than with the current macros, because scm_cons and scm_cons2
are also not inlined at the moment.  Thus, your solution does not
introduce any additional function calls, but instead might get rid of
some.

What about the idea to provide scm_listify as scm_list_n, used as
  scm_list_n (arg1, arg2, ..., SCM_UNDEFINED)
?  Note that we can't name it scm_list, because of name conflicts.  But,
it may be a good idea to use `n´ as a postfix anyway.  There are, however,
some names that do not yet fit into this pattern, at least I know about
scm_remember_upto_here, which also takes an arbitrary number of args.

Best regards,
Dirk Herrmann




reply via email to

[Prev in Thread] Current Thread [Next in Thread]