Hi, 1. Does any other system recompile stuff that set! a + operation 2. Isn't the least we should do to warn when a user set! + as I did in the last email 3. Wouldn't it be a good idea to allow a user to specify which basic vm op's would be translated to a macine instruction or not. So say that I would like to count the number of scheme + guile uses at startup, then I could specify in a configuration that + should not be comiled to a vm-op and then recompile guile and then use set!
On Sat, Feb 16, 2013 at 5:29 PM, Noah Lavine <noah.b.lav...@gmail.com> wrote: > 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 >> > > >
