Re: Patch for sC++ to GNU C++.

[Mark Mitchell <mark at markmitchell dot com>]

>>>>> "Joe" == Joe Buck <jbuck@Synopsys.COM> writes:

    >>  >>>>> "Joe" == Joe Buck <jbuck@synopsys.com> writes:
    >> 
    Joe> The idea is that there would be a new directory gcc/sc which
    Joe> would be a peer of gcc/cp.  It would contain all of the new
    Joe> sc-xxx.c files.  Initially, the parser would need to be
    Joe> duplicated and modified, which I don't much like.
    >>  Me neither.  In fact, I'm thinking about how to (partially)
    >> reunify the C and C++ front-ends.  Please, let's not duplicate
    >> any more code.

    Joe> As I mentioned, the alternative is to do something like
    Joe> c-parse.in (the technique used to share the C and Objective-C
    Joe> parsers).

You're probably noticing that I'm being contrary.  :-) Here's my
problem:

  o If we add a new front-end and duplicate all the files, we've
    duplicated all the files.  This necessitates changes in two
    places.  We have *way* too much of this as it is.

  o If we don't duplicate all the files, we then have to take the
    extensions into account when dealing with changes to the C++
    front-end.  Automatically generating variants of the files is
    essentially the same as this situation.  When we modify, say,
    type-checking, we must worry about breaking the other variant
    of the language.

That leads me to conclude that the right thing to do at the moment is
to have the people interested in the extension maintain their patches,
separately from g++.  I suspect that in about 6 months to a year we
will have done lot of the work remaining on the C++ front-end required
to reach feature-completeness, and that interfaces will have
stabilized considerably.  (For example, it's still quite likely that I
will rewrite the parser itself in the relatively near future.  I have
a client interested in this work, but it's not yet a high priority for
them.  I'd also be willing to do this work for someone else, if they
asked me.)

Once things have stabilized, we should consider the extension on its
merits.  Adding any extension always creates maintenance difficulties,
no matter how good the extension may be.  We have to weigh the utility
of the extension against these difficulties.  But, I don't think now
is the time to even begin that debate.

Jan, I understand that you have probably done an excellent job, and
that you feel the impact on the compiler is slight.  However, even
reasonably well-contained extensions can cause real maintenance
problems.  Please note that my arguments apply equally to *any*
extension; there is no implied criticism of yours relative to any
other.

-- 
Mark Mitchell 			mark@markmitchell.com
Mark Mitchell Consulting	http://www.markmitchell.com