Path: utzoo!attcan!uunet!saxony!dgil
From: dgil@pa.reuter.COM (Dave Gillett)
Newsgroups: comp.lang.c
Subject: Re: Request for Comments: Aggregate Assignment in C ...
Message-ID: <623@saxony.pa.reuter.COM>
Date: 11 Dec 90 21:21:31 GMT
References: <77546@iuvax.cs.indiana.edu>
Distribution: na
Organization: Reuter:file Inc  (A Reuter Company) Palo Alto, CA
Lines: 59

In <77546@iuvax.cs.indiana.edu> mayer@iuvax.cs.indiana.edu (Mayer Goldberg) writes:

>Pascal programmers who learn C, frequently complain of C's
>lack of a "with" construct. We propose an alternative to
>adding such a keyword, through a natural extention of C's
>aggregate initialization statement.
     .
     .
     .
>This solves the "with" problem in C. It also opens a delicious
>can of worms: Should the order of evaluation of the aggregated 
>expressions be specified? Perhaps not, for this would be in
>line with C's philosophy of not specifying the order of
>evaluation of parameters to a function, or alternately, we
>could demand a left-to-right order of evaluation as implied by
>the comma operator.


     On the contrary, it solves a *piece* of the "with" problem, and
introduces a can of worms which is not only delicious, but not present
in the Pascal "with" construct.

     Mayer's suggestion covers the case of aggregate assignment *to* a struct,
but does not even attempt to address references to struct elements as anything
other than targets of assignment.  Since Pascal's "with" applies to all
element references, regardless of context, the suggested enhancement cannot
be mistaken for an equivalent feature.
     If the comma is to be used, it seems preferable for it to retain as
much of its normal semantics as possible.  Indeed, I think it is already a
linguistic flaw for it to have different semantics as an argument delimiter
than as an operator.  Introducing a third semantics for a single symbol is
clearly not a good idea.
     Using the operator semantics should, it seems, yield a single rvalue
for the expression within the {}s.  [No, I didn't quote Mayer's entire article.]
So that leaves the function parameter semantics.  (At the moment, {} have
different semantics depending on whether one is looking at a variable
declaration or at code; leaking the variable definition semantics of {}
over into code, where they already have their own semantics, seems dubious.)

     Suppose, having decided to use the argument delimiter semantics of the
comma, we also steal the accompanying () semantics.  So "(a, b, ...)" is a
"list of values" construct, which can be assigned to a structure (under
suitable constraints) or passed as an argument list to a function.  (So
"()" is the empty list.)  So far, this looks like a powerful generalization
that shouldn't break existing code.
     The problem is that, if we define the paren/comma construct this way,
then "funcname structname;" should call function "funcname" passing the values
from struct "structname" as arguments.  That might be nice, but it's not C.

     Note that "funcname structname" is *not* equivalent to
"funcname (structname)".  The latter function takes a single struct
as an argument, not the elements of the struct as list of arguments.
You can make them equivalent in the compiler, but that gives you no way
to have a struct as one of a list of arguments, and so breaks existing
code.

     Mayer's suggestion points in the direction of APL's nested arrays or
LISP's lists.  But it's not C, and it's not Pascal's "with", either.
                                                   Dave