FORTRAN (was Re: indentation)

Tim Peters tim_one at email.msn.com
Fri Dec 10 03:48:53 EST 1999


[Christian Tismer]
> I'm 43,

Heh heh -- what a puppy.  Wet behind the ears, I tell you!

> and I learned FORTRAN IV right after Algol 64 in the late 70s.
> Can't remember if it was this, or an earlier Fortran version which
> had no dynamic variables but just statics?

[William B. Clodius]
> Tim Peters may correct me on this, but I believe that all Fortran's
> up to Fortran 90 could be implemented with static allocation. It had
> no recursion and, in most respects, no dynamic allocation.

No correction here!  That certainly matches my memories of implementing
Fortran.

In fact, in the mid 80's I was on an ANSI committee defining parallelism
extensions for Fortran, and one of the vendor representatives prevailed in
squashing anything that required so much as a *stack* (! quite a trick when
dealing with dynamic threads and thread-local COMMON and ...).

> The one tricky point in static allocation involves some usages of
> CHARACTER variables which result in expressions whose size can
> vary at runtime. However, I believe that the language defined a
> standard upper bound on the size of these expressions to allow
> static allocation in these cases. (No I can't cite a reference at
> this time.)

My memory on this is fuzzy too.  In general, the Fortran stds never said
anything about capacities, though; e.g., I don't think the std supported a
claim that more than one integer had to be representable -- or that *all*
integers *couldn't* be.  Similarly I don't think a conforming processor was
*required* to accept anything "bigger" than CHARACTER*1.  Such things were
left to common sense and the "natural" capacities of the target platforms:
speed at any cost.  Right on; Fortran served its audience well.

Cray (at least at the time) invented a "hidden" argument for every formal
CHARACTER argument, in which was passed the actual capacity of the actual
argument.  So, in general, supporting CHARACTER*(*) didn't require any
dynamic allocation, regardless of string size.

Trickier were chains of CHARACTER concatenations.  IIRC, the std prohibited
catenations involving a CHARACTER*(*) dummy argument unless it formed the
right-hand side of a character assignment stmt.  In this way, no strings of
"unknown" length could be passed as arguments, and in an assigment stmt you
could generate code to stop catenating the RHS as soon as the capacity of
the LHS character vrbl was reached (which in turn was either of fixed
declared size, or of dummy argument *(*) size and so had its true capacity
"secretly" passed in).

> ...
> As a side point, dynamic languages can also be implemented statically
> with defined limits on depth of recursion or sizes of dynamic entities,
> it is just wasteful of computer memory and implementor's time to make
> that an implementation goal on current user systems (there have been
> user systems in the past that only allowed static allocation and of
> course micro-controllers usually require static allocation).

Stacks will triumph when the last people who fear them finally die off --
although heaps may require the sacrifice of the generation following <wink>.
While there was much to love in the Fortran line, the Fortran 77 CHARACTER
hack has got to be the feeblest string gimmick implemented at the greatest
cost & clumsiness of any such facility in any language.  All to save some
measly mallocs.

python-still-makes-me-feel-like-a-rebel<wink>-ly y'rs  - tim






More information about the Python-list mailing list