Re: specifications (was Re: Languages: The Bigger the Uglier)

> For example, consider a language like Ada with multi-tasking. Almost
> any interleaving of tasks is legal. The "standard" implementation
> would have to execute all possible interleavings, which is so
> inefficient, it would typically take longer than the current age of
> the universe. It's not just a matter of adding a few checks here and
> there.


Perhaps I'm being incredibly dense here (wouldn't be the first time),
but I don't see why the "standard" implementation must execute all
possible interleavings. It would only have to be random. Thus if you
have a program that works on compiler A, but not on compiler B because
of a dependency on the implementation's execution order (I'm not
familiar enough with ADA to provide concrete example), running the
program with the standard compiler would tell you that the program is
not standard conforming and thus compiler B is not broken.


> True. But what if the langauge allows pass-by-reference or
> pass-by-copy, depending on the whim of the compiler writer, but
> neither one is considered "wrong".


I'm going to make some guesses about what you mean by this. I'm
guessing that you mean the standard states that if make a call like:


      f(a)


Then function 'f' should not reference the actual paramter 'a' by any
other way than via the formal parameter (after the formal parameter
has been modified) since the value of 'a' would be undefined at that
point because modifying the formal may modify the actual immediately,
or not until 'f' returns, depending on the implementation choice. I
don't see how this leads to combinatorial explosion. I would
implement variables with descriptors, where one bit of the descriptor
is "I'm undefined" and update that appropriately at run time.


Now, if you had mentioned order of evaluation of operands of binary
operators, I can see how that could be a combinatoric issue:


      (f()*g())*(h()*i())


If the language says it's undefined which side of '*' gets evaluated
first, one would ideally want to try all 24 orders. Instead, I would
pick a random order every time. Either at run time or at compile
time. While a single run does not tell you anything, you can
determine a program is standard conforming with a given certainty by
doing enough runs.


I suspect a (good) side effect of this discipline would be the
elimination of undefined behaviours from standards.


The point another person made about the real world being
Cray/DEC/IBM's implementation is well taken. I've always refered to
the situation as there being a "written" standard and an "oral"
standard (the situation being analogous to ancient Jewish legal
practice where there was the written Law in the Torah, and the oral
law, which eventually was written down in the Talmud).


Another person noted that he doubted the standard implementation would
be well debugged. Even if not, I think forcing the committee to have
to actually implement what they are standardizing would go a long way
towards removing ambiguity from the prose standard, even if the
"standard" implementation proved to be a useless in all other aspects.


--
Jeffrey Glen Jackson
--

Return to the comp.compilers page.
Search the comp.compilers archives again.