Hello, On Sat, Feb 16, 2013 at 2:14 PM, Mark H Weaver <m...@netris.org> wrote:
> 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. Interesting points. I think you're right that Tree-IL should be optimized first. For the specific issue of order of evaluation, I'm hoping to add something (either a special function or a special node type) to CPS to represent continuations that can be evaluated in any order. It seems like evaluation order is a decision that should be made in either the code generator or the register allocator, and those operate on CPS. I also dislike losing information. > > 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 see. That's very cool. > > > 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). > You mean if a function modifies another function that called it. Yes, that seems complicated. It's not very important to me to fix it in general, because I don't know of a case where it's useful. I think fixing it without the on-stack replacement would be a reasonable compromise. > Thanks for you work on this, Noah! > Thank you! Noah
