> > Too late. I'm going there... :) > Good for you. I was hoping transformations could make it :)
Why didn't you chime in support before, then? I feel like Aaron and I are the only ones who are opinionated on this matter... > Here's something I was wondering. Say you wanted to write a pow() macro > (from a previous example) that would forward to C's pow() unless the > exponent was an integer, in which case it would optimize to many *'s. If > it was called like so: > > pow(2.718, 2 * 6 / 3) Yeah, this is part of the problem of scheduling transformations. I believe it was mentioned to be NP-complete in the literature I read, but so are most compiler optimizations, and compilers usually use heuristics, so this problem shouldn't be unsolveable. As Nick said in a different email, this particular constant-folding problem can be solved by using a bottom-up approach. 2*pow(2.718,2*6); 2*6=>12 pow(2.718,12)=>constant 2*whatever=another constant The problem comes in when we allow additions to these transformations. Say we have a simple arithmetic constant-folding transformation that handles the operators. The pow operator, when we 'use' it from some module, would import the pow() constant-folding transformation, or somesuch. It's a bit of a contrived example since pow() will probably be included by default, and not be imported, but I think the scenario is still a valid one. If we have these two different constant-folding transformations, no ordering of them can solve the one I just presented. They need to be applied in an interleaved manner. In the worst case, after every transformation, the entire tree needs to be rechecked for every possible transformation. In this case, these transformations depend *only* on the nodes and subnodes, so we can limit the scope of where we have to re-check these constant-folding operations. If we define a constant-folding transformation category, then we can limit the checks to just those category of transformations. Another example, such as tagging blocks with 'uses eval-string', would need to be propogated up the blocks, and through called functions. This transformation would only occur on eval-string nodes. If we make a registry of nodetypes to applicable transformations (along with alist for the applies-to-all-nodes transformations), that should help a lot. Since getting all the places that call this uses-eval-string function isn't possible at compile-time, that shouldn't occur via transformations. But it's getting off-topic. Some transformations need to look accross the entire tree, but I figure these will be less popular in a language like perl, due to its dynamic nature. Which is good, since I think those kinds of transformations make for a much harder problem. An idea like this sort of has to permeate the design of the compiler, if everything is seriously going to be done with transformations. Perhaps it's too radical for us to use in Perl 6. I haven't heard any of the heavyweights chime in for or against the ideas of macros, transformations, and so on. What's the current plan in terms of allowing users to extend the perl syntax and grammar? I haven't really seen any discussion from Damian, Larry, Simon, etc on how this going to be accomplished. I don't see it being covered in apocalpypse, since the camel book never really covered the internals. :) I'm pushing for my own vision of what a compiler would look like, that achieves our goals. What other ideas are out there, that are more ground to earth than mine? Thanks, Mike Lambert PS: Yes, I know I write too much. :)
