Merger SETF-FUNCTION-VS-MACRO and SETF-PLACES proposals

[Jon L White <jonl@lucid.com>]

I object to the way in which this merger has been done *** in the
strongest possible way ***.

There has never before been an issue upon which the cleanup committee
successfully reported out two competing proposals.  We do not have an 
acceptable precedent for sending unresolved alternatives to the committee 
as a whole.  However, if we in the subcommittee are unable to decide to 
drop one of these two proposals, then the presentation of the positions 
pro and con should come from the active proponents of each side --- not 
 from your (misguided, I think) advocacy.

I agree that the two proposals should be presented as "being of one 
Issue, and being mutually incompatible"; but I most strongly disagree 
that the current Issue format is adequate for the blending in of 
seriously opposed alternatives.  The "common" sections of References,
Problem Description, Benefits, Rationale etc. presume a common
understanding of what the problem is.  But for the two proposals
at hand, the only common thread is the 10 lines (out of the 600 or so)
that call for setf expansions to defaultly turn into setf functions.

Furthermore, the attempted "merger" of the texts from the two proposals 
has led to one that is substantially longer, and substantially more 
complex, than the two separate ones standing by themselves.  For example, 
the setf-places version has only 9 items in the "References" section -- 
but the "merged" version has 25 items, 16 of which are irrelevant to and
distracting from the setf-places.  I would much much rather read two 
proposals of length N, than one co-mingled one of length 2N -- the
complexity measure of the latter can easily be 4 times greater than
that of either predecessor.

Oddly enough, I have the same feeling towards this issue as Moon, 
but from the other side of the fence.  I would be only mildly
disappointed if X3J13 decides as a whole to cram "function specs"
downs the throats of all those who have so vociferously rejected
them ("disappointed", because I don't think "function specs" are 
good enough -- not because I find lists-as-names disagreeable).  But
I would be thoroughly displeased if the committee loses focus on
the choices because the issue is far to complex to read now.   I'd
rather see the issue settled by a flip of a coin than risk having
yet more ways to go astray, or more things to argue unproductively
about.


-- JonL --