Hey Noha, Great work indeed.
Isn't the primitiveness decided by tree-il? you wil get a (<primcall> ...) tree il element and then should know how to emit a corresponding primitive instruction(s). Anyway I think that your conclusion is right, it would not make sense to support overwriting these primitives dynamically, but scheme@(guile-user)> (set! + (lambda x (apply * x))) scheme@(guile-user)> (+ 2 3) $1 = 6 scheme@(guile-user)> (define (f x y) (+ x y)) scheme@(guile-user)> ,x f Disassembly of #<procedure f (x y)>: 0 (assert-nargs-ee/locals 2) ;; 2 args, 0 locals 2 (local-ref 0) ;; `x' 4 (local-ref 1) ;; `y' 6 (add) 7 (return) So things are not consistent! BTW If you like I could work on getting define* and lambda* to work, I have that code in my branch and should be able to make it work on your branch as well. WDYT? /Stefan On Sat, Feb 16, 2013 at 1:53 AM, Noah Lavine <noah.b.lav...@gmail.com> wrote: > Hello, > > The wip-rtl-cps branch has been rebased again (on top of wip-rtl). It now > includes support for toplevel references and sets, thanks mostly to Andy's > work on supporting them in RTL. (Although you shouldn't kick that part of it > too hard just yet; I think I know where it will break.) Other highlights > include using the top-level variable support to evaluate "(+ 3 4)" > correctly. > > Overall, I think it's coming along well. The parts of Tree-IL that are left > to implement are local mutable variables (should be easy after toplevel > ones), module references and sets (very similar to top-level ones), > closures, and the dynamic environment stuff. Local mutable variables are my > next project, and then I think closures. > > One question I've had is, can we assume that the variables in the (guile) > module are immutable? I think the current compiler does this. Otherwise > there's no correct way to inline primitive procedures like + unless we have > a way to invalidate our compiled code and recompile it (which I would like > to have anyway, but that's a different story). > > Best, > Noah >
