and you compile it. arc2c would then inline f when called by g. Suppose now that I load the compiled file from the repl and then type:
(def f () 5)
now calling g from the repl should return 5, but f were inlined before, so it will return 8. Does arc2c handle this kind of problems? If it does, how is this implemented? I'm asking because I wanted to do a similar optimization in nyac, but this problem blocked me.
I wonder if there is a way to make that optimization work also when eval is used, maybe by tracking a dependecies list for every function, because it is really helpful. To make an example: the '- function takes a variable number of args, so all the arguments passed to it must be consed. With inlining it would be possible to avoid consing the arguments when they are known to be 1 or 2. To give you an idea of how much consing the args costs, take the fibonacci example: to calculate the 32nd number on NYAC when consing '- args it takes (on my computer) ~3.4 secs, without consing '- args it takes ~0.6 secs. This is a huge difference.
> 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.
True; I'm thinking of something like using a dependencies list like you suggested, and doing dynamic recompilation (inlining the code) when a function call is done a particular number of times. I then keep a reference to the original code, in case some member of the dependencies list is modified.
The problem here however lies in the severely parallel nature of SNAP. If I'm recompiling code, then I either make a (process-local!) copy, or I force everything to use (comparatively slow!) locks just to read code. The better choice is the process-local copy but it has the drawback that optimizations that run on one process won't get passed to another T.T unless SNAP is run in single-worker-thread mode.
