> Because there are some assertions that can lead the optimizer to make some > fundamental assumptions, and if those assumptions get violated or > redefined while you're in the middle of executing a function that makes > use of those assumptions, well... > > Changing a function from pure to impure, adding an overloaded operator, or > changing the core structure of a class can all result in code that needs > regeneration. That's no big deal for code you haven't executed yet, but if > you have: > > a = 1; > b = 12; > foo(); > c = a + b; > > and a and b are both passive classes, that can get transformed to > > a = 1; > b = 12; > foo(); > c = 13; > > but if foo changes the rules of the game (adding an overloaded + to a or > b's class) then the code in that sub could be incorrect. > > You can, of course, stop even potential optimization once the first "I can > change the rules" operation is found, but since even assignment can change > the rules that's where we are right now. We'd like to get better by > optimizing based on what we can see at compile time, but that's a very, > very difficult thing to do. How about retaining some "debug" info, (line number come to mind), but only at expression level?? So in your example if foo() changed the + operator, it would return into the calling_sub() at expression 4 (numbered from 1 here :-), notice that something has changed, recompile the sub, and continue processing at expression 4.
Phil
