🚀 go-pugleaf

In article <29224:Feb419:06:0191@kramden.acf.nyu.edu>, brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes:
> In article <1991Feb4.160639.2766@spool.cs.wisc.edu> quale@picard.cs.wisc.edu (Douglas E. Quale) writes:
> > Dan, sometimes I think we don't speak the same language.
> 
> Look, static allocation is not an ``arbitrary limit,'' and when you say
> ``fixed, arbitrary limit'' people will assume that the programmer used
> some fixed number, say 1000, as a limit. That's not true here.

If there is static allocation, then the number of distinct compositions
which can be "live" at any time has a FIXED LIMIT.  That's what static
allocation means, after all.

> Are you going to claim that Fortran has ``arbitrary limits'' because
> doesn't have dynamic allocation?

*Fortran* didn't have arbitrary limits on array sizes, but Fortran *PROGRAMS*
did.  (Fortran Extended -- was F8X -- is much better.)

> That's a restriction upon power: it's
> something the language can't do. It's not a fixed limit, and it's not an
> arbitrary limit.

But the size of any one array in old Fortran WAS a fixed limit, and in
general those limits were never satisfactory.  In the same way, an
implementation of function composition which uses static allocation
does involve each program instance running with a fixed (hence often
unsatisfactory) limit.  It would be fair to say that Fortran did not have
first-class arrays.  (I think it would be possible to argue that 8X has.)

> > The number of functions in a C program is limited to EXACTLY the number of
> > functions that are provided at compile time.  This number cannot be altered
> > (most crucially, increased) at run time.
> 
> Fine, so call it a limit if you're desperate. It's not a fixed limit,

But it IS a fixed limit.  If program P contains N function definitions,
then when processes execute P, they will have N functions, no more, no
less.  N is a fixed limit for that program, even though it isn't a fixed
limit for the *language*, and even though the limit can be set otherwise
for a variant P' of P.
> > How do you know, at compile time, EXACTLY how many composed functions
> > I want?

> I don't. You're the one writing the program.

The point is that NOBODY knows.  It's not all that rare for the execution
of a program written in a language with first-class functions to create
tens of millions of derived functions, just as C programs may perform
milliards of arithmetic operations.

-- 
The Marxists have merely _interpreted_ Marxism in various ways;
the point, however, is to _change_ it.		-- R. Hochhuth.