[Top][All Lists]

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

Re: towards a more unified procedure application mechanism

From: Andy Wingo
Subject: Re: towards a more unified procedure application mechanism
Date: Sun, 30 Aug 2009 17:45:56 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.92 (gnu/linux)

Hey folks,

I'd like to outline something of a plan.

The general outline is first to simplify dispatch, then to pull it into
the VM.

Ideally I would like to have only three kinds of procedures: VM
procedures, subrs, and applicable structs. It might not be possible to
simplify all of these, but we can try. We need to pay special attention
to avoiding unnecessary C API incompatibilities, but hopefully we have
sufficient room for refactoring.

On Sat 29 Aug 2009 13:38, Andy Wingo <address@hidden> writes:

>  scm_tc7_program            VM procedures
>    - native support


>  scm_tcs_closures           Interpreted procedures

I am hoping to devise a way never to see these in the VM, on the
eval-cleanup branch.

>  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

I'll probably do a:

#define scm_tc7_subr_2o \

or something like that.

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

>  scm_tc7_cxr                c[da]+r

I'll change these to be subrs.

>  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

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

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

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

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

Well, that's my plan. Let me know if you have any concerns. This work is
probably not for this release.


reply via email to

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