No subject

of incompleteness in our systems?  In truly mission-critical software (as
opposed to mere commercial systems in which the worst consequence of error
is some lost money), it would be disturbing to find that unintentional and
unnoticed dependencies were being addressed by automatically satisfying
them, even if we don't know where they are and haven't examined them.

I'd be concerned that these may cause latent errors to be uncovered by some
unexpected data inputs (think Ariane 5), or by a code change that should
have been innocuous, if not for an unnoticed dependency.  Rather than paper
over such potential errors and ignoring them, I would prefer to have a means
to stress-test code which claims to be free of order-dependencies.  To do
that, we need the means, in the language, for making the claim of
order-independence in the first place (a "declaration of independence", from
the Orwellian regime mentioned above).

It would seem strange that formal analysis is telling us that a language has
been made safer by fixed evaluation order, while real-world experience may
tell us otherwise - but this dichotomy is explained by the mismatch between
real systems, and the simplified language.

It's only by meta-sleight-of-hand that our focus has been redirected to a
narrower system.  We can't assume that safety within that system says
anything about the safety of real systems.

Of course, the basic issue is still the same - a subjective tradeoff between
pros and cons on either side.  I can see why semanticists would like the
simpler, more tractable system.  However, with the possible exception of
systems amenable to correctness proofs, it's not at all clear to me that
fixed evaluation order is on the side of real-world safety.

If there is under-specification present here, surely it is actually in the
language which disallows the specification of order independence, despite
such order independence being a manifest property of large parts of real
world systems?

> Is it possible to provide a complete specification of a language?
> I don't know. Languages are huge, complex artifacts. Take a look
> at the number system. Take a look at thread systems and similar
> things. I don't know whether we can do an adequate job. But that
> shouldn't prevent us from doing better than we have done in the
> past.  That's part of what PLT is about and I sure hope we can
> stay the course.

No argument there.

Anton