Re: Proposal

[Zack Weinberg <zack@codesourcery.com>]

On Tue, Sep 18, 2001 at 07:12:21PM +0100, Joseph S. Myers wrote:
> On Tue, 18 Sep 2001, Zack Weinberg wrote:
> 
> > I can tell you exactly what comp.std.c will say: Go away, implement
> > it, and get several years of experience with the extension, then come
> > back with a formal proposal.  The suggested extension (_ as a
> > separator in numbers) was actually proposed on comp.std.c just before
> > C99 was finalized, and they said just that.
> 
> Just before C99 was finalized wasn't an appropriate time for proposing new
> features; nor is now

Right - which is precisely why we *shouldn't* make proposers of
extensions run the gauntlet of comp.std.c or the WG14 reflector.

I would like to see us in a position to propose a set of useful
improvements to the standard in the next cycle, and that means
experimenting - both with our existing extensions and with new
ones.

I'm glad to hear the UK National Body is working on the existing
issues with the C standard, but that really doesn't affect the
original poster's proposal, which is about as independent of the
existing problems as you can get.  Which isn't to say that it is
perfect - I have concerns, though I like the idea in principle.
(see other message)

> > We have also been around this particular wheel with other extensions.
> > Does anyone remember __norestrict?  Your recipe is equivalent in
> > practice to "we will add no (more) extensions, ever."  Which is a
> > legitimate position to take, but only by coming out and saying so.  It
> > is unfair to run people through a lengthy bureaucratic procedure that
> > appears to offer the possibility of adding an extension, but will
> > always result in the extension being rejected.
> 
> The presumption must be against extensions because of the bad history of
> problems caused by extensions that are poorly defined or later cause
> problems in their interaction with new language features.

Certainly the presumption is against them, and in fact I think a
position of "no additional extensions at all" is extreme but
reasonable.  What I object to is your proposed procedure, which
_appears_ to be open to new extensions, but in practice is closed, and
will subject the proposers of extensions to a great deal of wasted
effort.  Again, remember __norestrict?

> > I'd also point out that very few people have access to the standard;
> > yes, ANSI sells copies for not-totally-outrageous sums, but many don't
> > know that and the cost may still be too high.
> 
> There is work in progress towards getting it published as a normal book
> (officially, not with value-subtracting annotations by Schildt) by a
> normal publisher whose books appear in bookshops.  (I don't have any more
> information about these plans.)

Oh good.

> > For all extensions, present or proposed, we either write up a formal
> > proposal to the standard committee, or we deprecate the extension.
> > The proposals are stored on the website.  Should we ever be in the
> 
> The proposals should be in the manual proper.

I'm not sure of this; would they be useful to normal users of GCC?
Standardization proposals tend to be written in standardese and
therefore are not suitable as end-user documentation.

Keep 'em in the tree, sure.

...
> (so that ISO have to negotiate with the FSF alone about the
> inclusion of such text in the standard, and this can be used as
> leverage to try to free the standard).

I don't think we should do that, it is likely to be counterproductive.
(I.e. I suspect the response would be to reject the proposals rather
than deal with the legal issues.)  Efforts to make the standard freely
distributable are laudable but should happen independently.

zw