Re: Implementation dependent behaviour (WAS: Re: Programming language and IDE design)

On 2013-11-20, Martin Ward <martin@gkc.org.uk> wrote:
> On Tuesday 19 Nov 2013 at 00:02, George Neuner <gneuner2@comcast.net> wrote:
>> I simply said that your assertion:
>>
>> (2) Absolutely no behaviour should be "implementation dependent"
>> or "undefined". Every syntactically valid program should have
>> a single semantically valid meaning (even if that meaning
>> is "halt with an error message").
>>
>> is not plausible. I did not offer an alternative.
>
> Your only counter-example is "execution time": but programming
> language specification documents have never included execution time as
> part of the specification of a language (whether defined as
> "implementation dependent" or otherwise). Execution time is not part
> of the specification of the language. Neither have they specified the
> power consumption or temperature of the CPU: although these properties
> can be just as important as execution time for certain applications!
> They are also not considered to be part of the definition of the
> language.


Indeed, if what is defined by the language specification is only what bits are
transformed into what other bits, then there is no reason not to have
a language that has no implementation-dependent behaviors.


There is still the issue of resources: the bits are transformed into other
bits in the requird way on platform A, and on platform B we get "out of memory".
But under no circumstances do we get a different string of bits.


Since highly portable programs that produce bit-exact results on multiple
platforms can be written in languages that have implementation-defined
behaviors, there is no reason why languages cannot themselves provide this,
at least with regard to their internal data structures.


There are practical concerns that stand in the way, at least one of
which is damning of the idea, however.


For instance, if you want bit-exact, platform-independent floating-point, you
may have to do it in software, at least in some implementations. This is going
to suck badly, performance wise. The practical approach is to design
application to have numerical stability in the face of differences in the
floating point system, which can be hard.


Operating system interfacing will be another sticky area, and I don't
just mean in particular things like POSIX signal handling, but even
basics like file handling.


For instance a text file on Windows contains carriage returns, but on
Unix it does not.


We generally *WANT* the text stream library of a programming language
to produce the correct text file representation externally, and
we want to use some platform-independent abstraction internally.


So, it is not sensible to to require a text stream library to be free of
implementation-defined behavior; it inherently embodies
implementation-dependent behavior. It's also not sensible not to have a text
stream library in a programming language. By doing that you can avoid the issue
in the language-definining document, but then programs have to insert carriage
returns explicitly when targetting Windows.


In other words, programs that produce text necessarily produce a different
bit string on different platforms: although those different bit strings
satisfy an equivalence relation based on normalizing to some common text
format: they are equal modulo text stream representation.


Never mind carriage returns; there are also character sets. Freedom from
platform-dependent behavior means that a program cannot print the letter
A. It must output an exact, platform-indepenent bit string, such as one
denoting the number 65, which will look like A on an ASCII or Unicode system.


I think that if you want maximal platform independence in a language, it is
best to focus that in the internal semantics of computation, and not insist on
total platform independence which encompasses the program's interaction with
the environment. There lies folly. (Or Java, but I repeat myself).

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