Re: Can someone spot the error here?

That was a pretty well reasoned overview, thank you.

frank@xxxxxxxx wrote:


Philosophically I do think it's an omission in original Pascal
(though not a serious one, since it can be easily worked-around).
You have a hidden "variable" there (at least something that behaves
like one on the LHS), but you can't access it. The idea was perhaps
that each function result should be computed atomically and assigned
at the end of a function. For some kinds of functions, this is
possible and good style (not to recall old prejudices WRT academic
language, but ...), while for others it's not (see above), and you
end up declaring an additional variable just so you can make that
single assignment(*). That's why I called the extra variable a
work-around, because it's really what you think of as the "result
variable" when you program, but you have to assign it to the real
result manually. Classic Pascal result variables do have a small
advantage over "return" statements (as e.g. in C) IMHO, in that you
can do extra work (such as cleanups) after the result assignment,
yet in some cases I prefer the "full thing", i.e. a read/write
result variable.

(*) I know there can be multiple assignments, but they usually don't
make much sense unless they're in different branches, so
effectively you usually have exactly one assignment per branch.

Frank


From a compiler writer's standpoint, the result needs to be created
at the bottom of a function, or as nearly at the bottom as possible.
The reason why is that a function result is optimally passed back
in a register, or even in a flag (for boolean results).

The emphasis on registered return values is based on the usage of
functions, and the optimization ripples outward from the function.
If the function result is returned in register(s), it is efficiently
used in expressions. In fact, the compiler can and should assume
that the results of an expression will have the following
properties:

1. That its life will be short-lived.

2. That the function result will be used immediately (a corollary
of the first rule).

3. That the result of a function may participate in some complexity
of expression.

All of this leads to the idea that the function result is best
prepared towards the end of the function. Certainly, other cases
where the function result preparation is further back in the function
will exist, but (as you mentioned) the programmer is at option to
illustrate these cases with local variables.

What I would state is going on here is basic communication between
the compiler writer and the programmer, which is, after all, what
a language like Pascal is founded on. The programmer sees a language
feature like the "odd and restricted use of function returns",
and realizes that the construct is pushing him/her towards a
certain methodology, that is, the use of function results as a
final step in the function, and not as a mid function calculation.
The result is preference towards efficiently compilable code, without
the need for the programmer to be studied in compiler construction.

Pascal, Wirth's Pascal, is full of such "B&D"[1] style constructions.
Wirth was looking both to compiler efficiency, and also enforcement
of good programming structure. Happily, in many or even most cases,
these two concepts are in agreement. For example, single entry/single
exit routines are not only good programmer practice, but also more
efficient to implement by the compiler, because they give the compiler
more chances to merge flows in the code.

I think I agree that Pascal's function result methodology is not
the correct answer for an idealized language such as Pascal is.
I would have preferred:

function x: y;

begin

end returning <expr>

Which would have made it clear that the result is to be prepared only
once, and very much at the termination of the function. This would
have made it more likely that the (perhaps unhappy) programmer had
created an optimizable construction, but would have also made it easier
to optimize the case in simple compilers.

To be fair, Wirth moved to the concept of a "return" statement in
Modula and Oberon, complete with immediate termination.

[1] "Bondage & Domination" language or somesuch. Its a label commonly
used to denigrate Pascal, but personally find complements Pascal
well.
.

Relevant Pages

  • Re: Letter to US Sen. Byron Dorgan re unpaid overtime
    ... >> considered to be a convenience by those who use the C language. ... I make no claims to being a VB.NET programmer. ... Ritchie SCREWED UP in designing the for loop because ... I do not believe that you are capable of writing a conforming C compiler. ...
    (comp.programming)
  • Re: why still use C?
    ... > to be at the mercy of the compiler and its designer, ... as a programmer I am no ... > program using templates and expect it to work identically on different ... > in mind that a programming language is a tool to make programs. ...
    (comp.lang.c)
  • Re: Letter to US Sen. Byron Dorgan re unpaid overtime
    ... a professional programmer however. ... >> The 'compiler mechanisms' for handlng for loops in various languages, ... I know Richard isn't so incompetent as to attempt to implement a compiler ... the defined semantics for that language. ...
    (comp.programming)
  • Re: Brian Kernighan, maybe Im not worthy, maybe Im scum
    ... what experienced programmers do, ... the compiler doesn't have the free pass to /assume/ that the function ... Nobody has recommended doing all optimization by hand to my knowledge. ... Compiler behavior in optimization simply has no place in a language ...
    (comp.programming)
  • Re: ADA Popularity Discussion Request
    ... other features, if you want mathematical precision, Ada can give it to you. ... It is certainly not as big a language as I think it ... compiler writers didn't thoroughly understand. ... So the efficiency thing kind of came about because of bad initial ...
    (comp.lang.ada)