Re: In-Out Parameters for functions

[David Starner <dvdeug@email.ro>]

On Wed, 04 Feb 2004 10:52:14 -0500, Hyman Rosen wrote:

> What is it about definite order of evaluation that you and so
> many others find intrinsically evil?

Have you ever studied functional programming? I think part of the
objection is the concept that pure functional programming is the ideal and
that we differ from that for efficiency and a closer mapping to the
hardware.

Also, half the examples have been horrible code that should never be
written. So much of the code enabled by this feature can't be fixed
to use it without a program-wide analysis of the problems, wherein it
would be just as easy to fix the code not to depend on evaluation order.

> OK, I accept that there are more ambiguity issues than I have
> been cnsidering. I suppose you object to getting rid of those too?

That would require major surgery to the language that would leave it
backwardly-incompatible or require the compiler to do stupid slow things.
If you want Java, you know where to find it.

In any case, you have a huge group of ambiguity issues around threads.
It's inherent in the system. If you're worried about your compiler
changing evaluation order at compile time, wait until your program starts
behaving erratically at run time because you made the same mistakes.

> But using functions that read input is not hard to reason about.
>      BunchOfReadings : array(1..100) of Integer := (others => ReadSensor);

Which it is easy to warn about and simple to fix.

> But it's not, except for programs which are now exhibiting unspecified
> behavior. If an expression has only one value regardless of execution
> order, then the compiler will be free to evaluate it in any order.

If the compiler can prove that, which is easier said then done. At best,
it will slow down compilers at compile-time, proving what they could
assume before, and slow down programs at run-time when they couldn't prove
it.