> With inlining it would be possible to avoid consing the arguments when they are known to be 1 or 2.
Hmm.
Since I control the VM anyway, it may be possible for me to add some sort of feature/bytecode/built-in-function that can perform reduction of arguments without consing (i.e. just by allocating a continuation function and reusing it). It would be possible to also have it "short-circuit" so to speak, prevent it from allocating a new closure and just pass its own called continuation directly to the child function.
Basically it would be like this:
(with (f0 (fn () (handle-0-arguments))
f1 (fn (a) (handle-1-argument a))
f2 (fn (a b) (handle-2-arguments a b)))
(fn rest ; not actually expanded into a list
; this will be implemented in C
(if
(no rest)
(f0) ; pass the continuation
(no (cdr rest))
(f1 (car rest))
(no (cdr:cdr rest))
(f2 (car rest) (cadr rest))
; perform reduction
(ccc
; enclose these variables
(with (a (f2 (car rest) (cadr rest))
rest (cdr:cdr rest))
; also enclose the continuation
(afn (k)
(zap a (f2 (car rest) (cadr rest)))
; rest will be an index into the
; closure variables
(if (zap cdr rest)
(self k)
(k a)))))))))
So handle-n-arguments is a special form? Exposing such a special form would break compatibility with both arcN.tar and Anarki, but this seems a good solution.
Nice! This way informations about SNAP will be no more spreaded in the forum. I suggest copying everything already present in the forum about SNAP into the blog.
It won't be exposed as a special form - rather it will be exposed as a bytecode, and the symbolcode-to-bytecode compiler will be exposed as a function that the implementation specific '$ will return. This should reduce the conceptual footprint of extensions to Arc that I add strictly for efficiency, versus actual axioms.
Basically we just grab $ as a sort of dispatcher for implementation-specific stuff (much like it is used to access mzscheme in Anarki), and put anything that is more-or-less implementation-specific there.