A few thought regarding Cray's "Variable Length Array Proposal"

[Tom MacDonald]

> rfg has objected to the same part of the VLA proposal that I objected
> to, the one that deals with order of arguments.
> 
> I know you have seen my proposals for how to modify just that one part.
> 
> When you respond to criticism of that part by offering Prosser's
> totally different scheme as if it were the only possible alternative,
> you are in effect pretending that options such as I proposed are
> unthinkable.
> 
> I think you should rewrite your reply, taking account of the alternatives
> that you should have acknowledged to begin with.

I did not mean to ignore your proposal, and I'm sorry this upset you.
I mentioned Prosser's proposal (which actually originated from Dennis
Ritchie) because that proposal was also voted out for a wider
distribution.  You're proposal was not voted out.  I understand Dave
Prosser is having some trouble actually getting his proposal ready
because of other pressures, but it should hit the streets before too
long.  I don't mean to imply that we shouldn't discuss your proposal,
I was just thinking more about the 2 competing proposals that were
voted out at the last meeting.

So, here is the last document you submitted to nceg about your
VLA proposal.  Please feel free to write more about it.

Tom MacDonald

===============================================================

X3J11.1/92-016		Richard Stallman	  3/17/92

   		Variable Length Array Parameters
		       A Simple Solution


The NCEG is considering several unsatisfactory syntax alternatives for
declaring functions that take variable-sized array parameters.

One approach requires use of old-fashioned C syntax for function
definitions; this is not a practical problem, since the same functions
can have declarations as well which give them prototypes, but it
contradicts in spirit the aim of deprecating old-style function
definitions.

Another approach requires parsing the argument declarations out of
order.  This violates the basic one-pass parsing principle of C
syntax, and the rule that an identifier's type should be known before
it appears in an expression.  It is painful to implement in certain
kinds of parsers, and makes the language definition wrinkled.

In X3J11.1/92-001 I proposed an approach which avoids those problems
but requires a new syntactic construct, which people would rather
avoid.

Here is another approach (originally proposed last fall) which avoids
all those problems.  The idea is to allow forward declarations of
arguments, within the argument list.  These are analogous to forward
declarations of functions, and serve the same purpose: to allow the
name to be used before its real definition.

More precisely, forward parameter declarations are written inside the
parentheses of a function declarator, and they look just like ordinary
parameter declarations.  But each group of forward parameter
declarations is followed by a semicolon.  The presence of a following
semicolon is what distinguishes forward parameter declarations from
real ones.

The real declarations alone determine the order in which parameters
are passed to the function.  The sole purpose of a forward parameter
declaration is to begin the scope of a parameter name.

Thus, the declaration for a function that takes two n*n square arrays
followed by the number n could look like this:

    int foo (int n; float a[n][n], float b[n][n], int n);

Just as now, each parameter must have one and only one real
declaration.  The change is that it can also optionally have any
number of forward declarations.  Every forward parameter declaration
must match a real parameter declaration.  All the declarations of any
one parameter name must agree in type.

This syntax requires just a small extension to existing function
syntax, and the meaning of the construct is unforgettable once you
have learned it.  It is completely flexible in regard to the order of
parameters, as well as the kinds of expressions that may appear in the
array sizes.  It applies to function definitions and declarations
alike.

I have implemented this syntax with a LALR(1) parser generator.
It seems to work.

Please consider my previous suggestion found in X3J11.1/92-001 as
withdrawn and superseded by this one.