Re: towards a more unified procedure application mechanism

[Andy Wingo <wingo@pobox.com>]

Hi Ludovic,

On Mon 31 Aug 2009 10:42, ludo@gnu.org (Ludovic Courtès) writes:

> Andy Wingo <wingo@pobox.com> writes:
>
>>>  scm_tc7_subr_2o            SCM (*) () -- 0 arguments.
>>>  scm_tc7_subr_1             SCM (*) (SCM) -- 1 argument.
>>>  scm_tc7_subr_1o            SCM (*) (SCM) -- 1 optional argument.
>>>  scm_tc7_subr_2o            SCM (*) (SCM, SCM) -- 2 required args.
>>>  scm_tc7_subr_2o            SCM (*) (SCM, SCM) -- 2 optional args.
>>>  scm_tc7_subr_3             SCM (*) (SCM, SCM, SCM) -- 3 required args.
>>>  scm_tc7_lsubr              SCM (*) (SCM) -- list subrs
>>>  scm_tc7_lsubr_2            SCM (*) (SCM, SCM, SCM)
>>
>> I would like to make these all be gsubrs. There are very few places
>> where these constants actually exist in code "out there" -- normally the
>> way to do this is to use scm_c_define_gsubr, and it does the right
>> thing.
>>
>> I'll probably do a:
>>
>> #define scm_tc7_subr_2o \
>>   scm_tc7_subr_2o_NO_LONGER_EXISTS_USE_scm_c_define_gsubr
>>
>> or something like that.
>
> You can't do that because such subrs are created by `create_gsubr ()'
> when the signature allows it.  Or did you mean `create_gsubr ()' would
> now create only gsubrs?

Yes, I mean for create_gsubr to return gsubrs.

> These specialized subr types allow for faster dispatch, as opposed to
> the argument count checks (and argument copies) that are done in
> `scm_i_gsubr_apply ()'.  Thus, I think replacing all of them with gsubrs
> may have a negative impact performance-wise.

That might be true with the current implementation, but it need not be
true with dispatch in the VM. The specialized subr types don't actually
gain us anything; you can do a gsubr dispatch just as fast, comparing
the tc16 instead of the tc7.

>>>  scm_tc7_dsubr              double (*) (double) -- double subrs
>>
>> I'll remove these, changing their implementations to be gsubrs. This
>> only affects $sin et al; I'll probably roll the transcendental versions
>> into the subrs as well.
>
> Yes, it seems to be seldom used.  However, it might be a semi-public
> API...

Undocumented of course. I seriously doubt this removal will cause
problems.

> Sounds like a nice plan!

We'll see how it goes :) This will be on my subr-simplification branch.

A
-- 
http://wingolog.org/