John Reagan wrote:
> scott moore wrote:
>
>> The result register is not an ordinary register. Because it only has to
>> be loaded at the exit of the function, it does not compete for
resources
>> with any other register.
>
> Maybe on your machines the result register is special, but on VAX,
> Alpha, and Itanium, the result register is normal register. I can be
> used for anything right up to the point where the function returns.
I wasn't referring to that (any kind of machine special register). The
function result is a special allocation because it can overlap one of
the input parameters, and only needs to exist at the end of the
function.
> Classic Pascal already has the weird function result variable that
> wasn't a real variable. It was already special cased in the grammer.
> Throw some of the mud at Wirth.
Sure, even Wirth (apparently) agrees, he went with the much clearer
notion of a return statement. My personal favorite would be
function x;
begin
end <result>;
Which makes it abundantly clear that the result occurs in a single
point at the end of the function.
However, this simply means that the extended standard promoted what
was a zit into a full on hemorrhage, so why this traces back to Wirth
escapes me.
> There are several parts of EP that I think were a waste of time both to
> define and to implement.
And here is the key statement, and why we are on different pages even
though we agree on many subjects. Those features are there in the
standard because of compromise between the parties involved in the
standard. How could it have been different? The standards process
is all about compromise, that is how a standard is made. That's not
what I have issue with.
The root of the problem is that it was left to the standards committee
to DESIGN the extension to the language. I would assert that is
something no committee should do. The Algol 68 standard that Wirth
created Pascal in protest of was designed by committee. Certainly
Algol 68 might have been an im****tant language, but it was
"kitchen sink" standard that was overcomplex and forgotten.
The best language standards were those with few (or one) designers,
and plenty of existing implementations with high efficiency, that
subsequently went into the standards process for clarification.
The extended standard fails virtually all of my concerns. It was
neither complete, nor had an efficient implementation at the
start of the standards process.
If I may wax philosophical, this dichotomy of standardization can
be solved by looking at the reasons for standardization. Compromise
between parties is not a constructive act, it is a process whereby
an existing design or process is (hopefully) saved from a destruction
of lack of standardization.
Confusing compromise with construction is a prime fault, in this
writers opinion, with the current standards process (there are others
that I won't go into). Perhaps the final epitaph of the Pascal
standards process is that it failed to achieve compromise with the
im****tant parties shaping the language (for which I include both
the original and extended standards), and subsequently failed to
result in even a single, complete and efficient implementation
(for which I refer to the extended standard).
This is the difference between a standard as a foundation for the
future, and a standard that is a pretty and well constructed
tombstone for a language, as Algol 68 so exemplifies.
Scott Moore
|
