Hello,
On Sat, Feb 16, 2013 at 2:39 AM, Stefan Israelsson Tampe < stefan.ita...@gmail.com> wrote: > > 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). Oh, you're right. I was thinking about that because I don't run the Tree-IL optimizers when I test it, so I don't get any Tree-IL primitives. Eventually maybe the primitive generation should happen in CPS, but I don't think it has to happen all at once. > 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! > Good example! This looks like a bug to me. I think I read that loading GOOPS turns things like '+ into generic operations - that might be a case where this matters a lot. I have thought a bit about how to fix this. The module system already allows us to be notified whenever a variable changes, so it would be easy to watch all of the variables in (guile) and recompile procedures when they change. I might take a look at this soon. > 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? Thanks, but I haven't even gotten far enough to think about this. I'm still working on getting all of the basic features going. After that I would definitely like define* and lambda*. Noah > > /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 > > >
