Hello,


On Sat, Feb 16, 2013 at 2:39 AM, Stefan Israelsson Tampe <
stefan.itampe@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.lavine@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
> >
>