🚀 go-pugleaf

In article <867@jhunix.HCF.JHU.EDU>,
ins_balb@jhunix (Andrew Barnert (Smilin' Jack // ex-God // etc.)) wrote: 
>
>In article <11860@haddock> karl@haddock.ima.isc.com (Karl Heuer) asked:
>
>>Would [label format for array elements] be workable?
>Yes, but as arrays are inherently ordered, 
>there's no reason to ignore the ordering ...
         ^^ ^^^^^^
>... the comma-separated format is much better for small arrays ...
                                               ^^^^^
>In the case of unions and structures, on the other hand, [labelled format]
>makes sense, as they are ordered only because it is necessary.

As an illustration of the counterexample you might have anticipated,
consider an operator table in a compiler (naturally, I believe that my
somewhat different syntax is *better* :-) 

	union { int precedence; float cost; char *name; } opr_tbl[opr_upb] = {
		...			/* approx. 100 leading entries */
		multd:	{2,50.0, "dp_mult"},
		multf:	{2,20.0, "sp_mult"},
		multi:	{2, 5.0, "int_mult"},
		nandw:	{4, 1.0, "word_nand"},
		negi:	{1, 1.0, "int_neg"},
		norw: 	{4, 1.0, "word_nor"},
		notw: 	{1, 1.0, "word_not"},
		...			/* approx. 100 trailing entries */
	};

Although one could order the enumeration values alphabetically,
there are algorithmic advantages to *ordering* the enumerated values 
by operator category (e.g., logical vs. integer vs. floating-point), or
precedence, but it is preferable not to forfeit the potential readability 
advantages of *presenting* the operator table in alphabetical order.

>It would probably be best to allow any complex type to use
>either the labelled format or the comma-separated format ...

Allowing both provides both algorithmic and readability benefits,
so I agree that it would indeed be best to allow both alternatives 
on the condition that it did not impose an unacceptable cost to do so.

Language designers can't anticipate all of the ways in which features
they design can be put to beneficial use by a conscientious programmer.
*Please* do not preempt decisions by the programmer simply because *you*,
as language or feature designer, can't think of a reason to allow
something whose inclusion imposes little cost, or even *avoids* a cost
(i.e., checking to enforce a somewhat arbitrary restriction).

Bill Wulf and Mary Shaw wrote an informal paper about the preemption
problem a few years ago in SIGPLan (excuse errors in quasi-"refer" format):

	%A Mary Shaw
	%A William A. Wulf
	%T Toward relaxing assumptions in languages and their implementations
	%J SIGPLan Notices
	%V 15
	%N  3
	%D March 1980
	%P 45..61
-- 
[The foregoing may or may not represent the position, if any, of my employer, ]
[ who is identified solely to allow the reader to account for personal biases.]
 
Clay Phipps                         {ingr,pyramid,sri-unix!hplabs}!garth!phipps
Intergraph APD, 2400#4 Geng Road, Palo Alto, CA 93403              415/494-8800