Opcode compatible division

[Bengt Richter]

On Wed, 25 Jul 2001 20:15:10 GMT, Guido van Rossum <guido at python.org> wrote:

>com-nospam at ccraig.org (Christopher A. Craig) writes:
>
>> I was wondering if it would be possible to add two new opcodes to the
>> VM language which I will refer to as ExactDivide and IntegerDivide and
>> keep the current opcode with its current behavior?
>> 
>> Even if there was no way in the actual language to generate the
>> CurrentDivide opcode, its existance would allow modules compiled and
>> distributed under the current system to continue to work with future
>> revisions.
>>
>> I haven't thought this through that much, so it may be a totally
>> stupid idea, but I thought it might fix some of the issues with
>> backwards compatibility.
>
>Check out my patch on SourceForge: it does exactly that.
>
>http://sourceforge.net/tracker/index.php?func=detail&aid=443474&group_id=5470&atid=305470
>

Is from future a one-way effect for the rest of the interpreter's execution?

I.e., one could conceive of pushing a fresh default state on a special (thread-owned?)
stack every time one opened a file for interpretation, and if the file contained a
from-future mod, just modifying the state topmost on the stack, and popping it when
done with the file.

The effect of alternate interpretation would persist in the compiled bytecode, as
made possible by new byte codes a la your patch. Compiling a string would be governed by the
current top of stack state, I would guess.

If pushing and popping this kind of state also became VM byte codes, byte code
containing an exec string could be properly affected.

One could imagine a version requirement operating on the topmost stack state similarly,
to implement per-file version compatibility mods, so long as the latest VM bytecodes
were a superset of older versions.

If from-future dynamically modifies the run-time to alter the meaning of byte codes,
rather than influencing the compilation to generate different byte codes for different
meanings, that would be different can of worms, I would imagine.

BTW, even though the version/compatibility issue is still steeped in the emotion of
the '/' discussion, I hope it can later be revisited as an important issue in itself,
whatever the anti-merits of using it as a '/' wart presever.

BTW2, I think Christopher's post is an interesting reminder that there's a
bottom-up as well as top-down aspect to all this.

BTW3 I expect generation of graminit.c could be automated on windows by setting
up custom build and dependency stuff in the relevant projects re the grammar files.
I've done it for a similar situation with flex. I don't see why you couldn't
run pgen in a similar way. Of course, pgen has to be built first.