Leo -- > > > ... Having major changes in opsfiles will invalidate PBCs, as > > > e.g. a change from gcc 2.x to 3.x invalidates C++ object files. > > > > I disagree that it is too expensive, but I expect it will require > > hard data to settle the matter. Since this is my pet issue, I > > expect you won't be surprised when I say invalidating PBC files > > isn't necessary, and therefore we shouldn't feel obligated to > > follow past practice in that regard. > > So lets have a closer look: > > - a new opcode emerges => put it into a new opsfile. Done.[1] > (in the next major release, it can go, where it belongs to)
I suggest putting it in with the other similar ops. A new core op in core.ops, a new math op in math.ops, whatever. > - a opcode is obsoleted => you can't delete it anyway, so keep it, > update docs. Aside: Begs the question: Should op metadata include an 'obsolete' tag? It would allow you to report on obsolete op use. > - a opcode gets more or less or changed params => you are as out of luck > with the old PBC as my approach is: invalidate PBC file. Nope. The op 'name' includes the number and types of the args, foo_i_ic. A "change" involves a new op and marking the old one obsolete. As far as existing bytecode is concerned an op signature change is equivalent to an op deletion and an op addition, and therefore should not be treated as a separate case. Removing an op instead of marking it obsolete will cause the oplookup to fail, and the interpreter would report and error, just as with finger- printing. However, you would actually have more information to report, such as which op is missing from which oplib, which can be helpful in tracking down the problem. So, IMO, the finer granularity is useful both for evolution and for failure diagnosis. When I first introduced fingerprinting, it was a quick hack to keep me out of trouble. I didn't want to spend a bunch of time debugging a problem only to discover it was caused by having a stale PBC. When I introduced the dynamic optable stuff, it was due to my fondness for the dynamic aspects of Perl and Parrot. I'm interested in pushing to see how deep the dynamic stuff can go. In the end, it may turn out that this stuff is possible but impractical... I haven't been able to come up with a way to determine that without trying it (and, :(, I have not had the time to actually try it out on a private copy -- in large part because the supporting infrastructure for dynamic oplibs isn't there yet, and its a big task to build that *and* do the fully dynamic experiment). Regards, -- Gregor
