> If I never had to create the virtual table, would it be a violation of the spec if I didn’t do it?

Generally: no. Most such specs have a phrase along the lines of “externally observable effect”.

In other words, the compiler can do anything as long as the programmer or external systems can’t tell that anything is different.

Processors do this all the time, reordering instruction execution but then arranging things so that it’s impossible to tell that this occurred.

For your latter point I find branch prediction to be even more egregious (from a computational ambiguity perspective). The processor is executing code just in case it discovers that it needs to have executed it.

Yup. Its an interesting example of deliberate ambiguity, and how useful it can be.

This is why I don't like using "ambiguous" as a term of abuse. Ambiguity isn't inherently bad. Languages are ambiguous for a reason.

But this can be unambiguously defined! Externally observable effects can have specific meanings.

I didn't quite understand that point, can you rephrase? I mean, yeah, things like specs for computer languages do define a space for ambiguity, but that space is ambiguous just the same.

Let's say you wrote this code:

    a = 2 * b + c * d;
    writeToDisk(a)
    e = b + b - a;
    sendToNetwork(e)

Naively, you would expect the compiler to emit CPU instructions that perform the computations left-to-right, top-to-bottom. In pseudocode assembly:

    mul 2, b -> a
    mul c, d -> reg1
    add a, reg1 -> a
    push a 
    call writeToDisk
    mov b -> reg1
    add b, reg1 -> reg1
    sub a, reg -> e
    push e
    call sendToNetwork

The externally observable effects may be considered to be the function calls. If you're dealing with I/O devices then it would be some similar specific hardware event such as writing to a GPIO register.

It should be immediately obvious that the compiler can compute 2*b just once, cache it in a register, and use it to compute both 'a' and 'e', even though the formulas are different and interspersed with function calls. Similarly, it can noticed that e has a 2b-2b in its overall formula and hence eliminate some computations entirely.

As long as the inputs to the functions don't change and the order of their calls aren't modified, "all is fine" and the compiler is free to do this.

In fact, modern compilers can completely eliminate function calls, inlining them if they perform pure computations or have no side-effects! This is done to such a point that it makes benchmarking challenging: merely timing some computations will often take 0 time unless the result of the computation is written to the console or some similarly externally-visible destination.

Compilers are allowed to this even for abstractions like virtual functions or interfaces. The JVM does this regularly. If it notices there's only a single implementation of an interface, it'll inline it, possibly eliminating the call entirely if it turns out to be a no-op.

Ok, thanks for clarifying. But again, we are so used to dealing with ambiguity that we don't even notice it. It looks like the inputs/outputs are really nailed down....but still, it is ambiguous in countless ways.

For example, you can type the input/output to these functions in any font or size you want. You don't have to use ASCII. The results on the screen can be glowing green phosphorus, red phosphorus, or a glorious retina display.

etc etc. Wherever the specs end, the ambiguity begins.