Re: Is multi-level function return possible?

On 24/03/14 17:06, Anton Ertl wrote:
>>> Keeping a feature may just be loyalty, but adding it back after it had
>>> been removed says something about what the language designer thought
>>> about the usefulness of the feature.
>> Well, it certainly implies that the designer [or the committee!]
>> is admitting to a mistake.
> In the case of the C branch of the Algol family, I very much doubt
> that the designers see it that way. B had a reduced feature set not
> because the language designer did not like the features they removed,
> but because B had to work on a very small machine. They added some
> features back in C, which ran on larger machines.


But B and C are different languages, with differing design aims
and criteria. Having a feature in C that was absent from B is not the
same as adding to C a feature that had previously been removed. K&R C
was not B Mk 2, but a new language with inputs [conscious or unconscious]
from many languages, including (B)(CPL) and Algol 68.


OTOH, modern versions of C have several features missing from
K&R C but present in [eg] Algol. Presumably the committee at least
feels that their omission had been a mistake; I don't know whether K&R
felt the same way.


> The designers of
> C++, Java and C# are different persons than the designers of B and C,
> so if they add a feature, why would they see it as "admitting to a
> mistake"?


Again, these are different languages and it's one thing to design
a new language with new aims [which may include being leaner and meaner
than earlier languages], and quite another to revise a language to include
features previously dropped.


>> [...]
>>> "Parameters have a run-time cost": So has access to non-local
>>> variables.
>> That depends on the machine and compiler. The first compiler I
>> used extensively [for Atlas Autocode] accessed variables at lexical
>> depth N by offsetting from register N, so all variables were accessed
>> at exactly the same cost.
> So this compiler maintained a display in the registers. The costs here are:
> 1) Accessing the variable in memory, whereas a parameter can be passed
> in a register and accessed in a register.


As above, it depends on the machine and compiler. On Atlas, the
registers were 24 bits whereas most parameters were 48 bits. Integers
were usually stored as denormalised reals [ie, also 48 bits] because
multiplications and divisions had to be done in the accumulator anyway
[and there were only very limited shift instructions].


> 2) Maintaining the display. AFAIK it turned out that maintaining the
> display is more costly in typical uses than the access cost it saves,
> so displays fell out of favour.


Well, it's one instruction on entry to a procedure and one on
exit, so it's not exactly expensive. It's certainly cheaper than passing
several parameters around all the time, so the overall balance depends on
how many and how often intermediate variables are used. I thought that
displays fell out of favour more because of a paucity of registers? Not
many minis and micros had the 100+ available to the general user on Atlas.


But in any case, you are again looking only at the cost in terms
of computing resources, and not at the programmer's view. The notions of
"literate" or "top-down" programming may have fallen out of favour, but
in the pre-Unix era [after which the emphasis switched to tools and to
libraries] it was natural to write programs in the form of nested
procedures, each of which was expanded in turn as the program developed.
Functions also were naturally written within the procedures where they
were used, and variables were declared at the most natural level for
their life-times. It's not impossible to write C programs that way, but
it's much harder than the equivalent [eg] Pascal.


> [We do forget that Ritchie's C compiler ran in 12K bytes of RAM,
> two passes plus assembler, and generated quite respectable code
> for the PDP-11. -John]


12K? Luxury. Why, in my day, .... But some early compilers ran
in ridiculously small computers by modern standards.


--
Andy Walker,
Nottingham.
[C was influenced by PL/I. C++ is where the Algol68 got mixed in, and some
of the C++ stuff was backported into C. -John]

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