Luke Palmer [mailto:[EMAIL PROTECTED]] wrote: > Then the macro would not recieve 4 as the second argument, > rather 2*6/3 in syntax tree form. Would the macro have to > do its own constant folding? I hope not. So how could it > check whether this thing was an integer? How could it > differentiate that from pow(2.718, 2 * 6 / 5) ? Or > would any constant folding take place before it was passed > to the macro?
For some reason, I am reminded of Microsoft's "Intentional Programming" reseach project. That system worked by allowing transformers to be coded against a graph representation of the software. I seem to recall that they had a pattern match against the graph the determine when to invoke a transform; and that the patterns were re-evaluated after every transform. Sounds a bit too heavy-weight for a run-time compiled language like perl I think we could achieve similar results by defining the the sequence of steps in compilation/interpretation; and allowing a transform to include code at every step. If each step is a tree-traversal, then you'd have hooks for pre- in- and post- order evaluation. Dave. p.s. the concept of transforms seems like a much better idea than that of macros. For one thing, it doesn't require any new syntax!
