Noah Lavine <noah.b.lav...@gmail.com> writes:
> 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.
I think you should be running the existing tree-il passes before you
convert to CPS. As I pointed out earlier, many optimizers will not be
able to work well after conversion to CPS, fundamentally because CPS
loses information about where order of evaluation is unspecified.
Furthermore, some of the existing passes make important simplifications
to the resulting tree-il. For example, the code in fix-letrec.scm
eliminates all <letrec> nodes, so that's one less thing for you to have
to implement. Primitives.scm marks primitives explicitly using
<primcall> tree-il nodes, so that later code doesn't have to make thorny
assumptions about what variables should be considered primitives.
> I think I read that loading GOOPS turns things like '+ into generic
> operations - that might be a case where this matters a lot.
No, because GOOPS has a special mechanism for cases like '+': they are
called "primitive generics". When numerical operations are unable to
handle the argument types provided, they calls 'scm_wta_dispatch_*'.
Therefore, adding new methods to numerical operations does not involve
changing their bindings. This is good because it means that you can
extend numerical operations without slowing them down at all for
built-in numbers.
> 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.
This would be nice too, of course, but I warn you that it's a can of
worms. In the general case, it involves on-stack replacement, because
you might need to recompile a procedure that's currently in the middle
of being run, and thus currently has activation records on the stack(s).
Thanks for you work on this, Noah!
Mark
