This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Proposal


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]