Aaron Sherman writes: : > Alternately, I think we should be able to mark subs as 'final' or 'inline' : > to indicate our guarantee that they won't be modified. Of course, it'll : > conflict with auto memoizing or auto currying modules that'd want to : > override it, but that's their fault. :) : : Yes, I suggested "inline" or "const".... I can't imagine that we would : want to do without this, regardless of what we call it. Otherwise, : auto-accessors will always be slower than using the variable. Would : everyone agree that this property should default to being set for : auto-accessors?
No, that would undo the whole point of making them accessors in the first place. : > And even though distributed .pbc files and seperate compilation are some : > goals of perl6, I still think we're okay. If we inline a function in : > module A, and module A changes, Perl6 should ensure that the original : > version is still loaded for our code, and thus our inlining should still : > be valid. : : Oh, that one's easy (I think/hope/pray). : : There're three stages: : : 1. "compile time" -- When a module or program is byte-coded : 2. "load time" -- When byte-code is loaded off of disk : 3. "run time" -- When the program begins to execute : : There are complexities, but you get the idea. "Load time", I assume is : also when BEGIN executes. Actually, BEGIN has to execute at compile time. INIT runs between load time and run time. : In this model, you only ever inline at load time ***OR*** when the : compiler is attempting to produce a self-contained byte-code executable : (e.g. one which has all of the modules in it), in which case it executes : that part of the load time process early. If you like, call this a : sub-stage of load time, which I shall dub "link time". Link time can : only happen once per program, so it must happen when we actually know : what all of the program components are. It seems like an assumption that link time can only happen once. An incremental linker might feel like it can relink any time it feels like it. Some very useful programs never completely know what their components are. : Any other way of doing this would seem to me to be a very dangerous : weapon to brandish so close to so many unsuspecting feet. :-( We've never shied away from issuing people enough rope. But I don't think that has to be the case here. We'll likely have an inline property. : > Another avenue is that of self-modifying code. I know it would break : > threads, or cause code duplication between threads, but when A changes, we : > can either re-inline the new subroutine, or eliminate the 'if-else' check : > to avoid the branch we know will be false from then on. Creating code : > which optimizes itself as it's run based upon internal profiling would be : > cool. But that's the topic of a different thread. :) : : Code that does this by changing sub references should still work. Code : that does this by changing its own internal representation gets what it : paid for. But methods don't have a unique sub ref until you know the type. One could inline a jump table of sub refs based on known types, and default to ordinary method lookup for unknown types. But there's no guarantee that would actually be faster than a decent vtable lookup. Larry
