[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: towards a more unified procedure application mechanism
From: |
Ludovic Courtès |
Subject: |
Re: towards a more unified procedure application mechanism |
Date: |
Mon, 31 Aug 2009 10:42:55 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) |
Hi!
Andy Wingo <address@hidden> writes:
[...]
>> scm_tcs_closures Interpreted procedures
>
> I am hoping to devise a way never to see these in the VM, on the
> eval-cleanup branch.
Cool!
>> 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?
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.
>> 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...
>> scm_tc7_cxr c[da]+r
>
> I'll change these to be subrs.
OK (this was essentially an interpreter hack AIUI).
>> scm_tc7_asubr SCM (*) (SCM, SCM) -- "accumulating" subrs.
>
> These are interesting. We have to keep the C signature of e.g. scm_sum,
> otherwise many things would break. So I'd change scm_sum to be a gsubr
> with two optional arguments, and then on the Scheme level do something
> like:
>
> (define +
> (let (($+ +))
> (lambda args
> (cond ((null? args) ($+))
> ((null? (cdr args)) ($+ (car args)))
> ((null? (cddr args)) ($+ (car args) (cadr args)))
> (else (apply + ($+ (car args) (cadr args)) (cddr args)))))))
>
> The VM already compiles (+ a b c) to (add (add a b) c), where add is a
> primitive binary instruction.
OK.
>> scm_tc7_rpsubr SCM (*) (SCM, SCM) -- predicate subrs.
>
> Likewise, we'll have to do something like the + case.
>
>> scm_tc7_smob Applicable smobs
>
> Well... we probably have to support these also as a primitive procedure
> type. It could be we rework smobs in terms of structs, and if that
> happens, we can use applicable structs -- but barring that, this would
> be a fourth procedure type.
Yes.
>> scm_tc7_gsubr Generic subrs
>
> Actually applying gsubrs can be complicated, due to optional args, rest
> args, and the lack of `apply' in C. I guess we should farm out
> application to a scm_i_gsubr_applyv trampoline that takes its args as an
> on-the-stack vector.
Indeed.
>> scm_tc7_pws Procedures with setters
>> Gets the procedure, and applies that. This needs to be inlined into
>> the VM to preserve tail recursion.
>
> Ideally these would be implemented as applicable structs. We'll see.
>
>> scm_tcs_struct Applicable structs
>
> Check if the struct is applicable, and if so apply its effective method.
Sounds like a nice plan!
Thanks,
Ludo'.