This is the mail archive of the 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]
Other format: [Raw text]

Re: [RFC] type safe trees

Geoff Keating wrote:
The language one is why don't we do this in C++ and be done? If
we were starting from a clean slate, that'd be a nobrainer. We're not.
Anyway, there seems to be buy in from several global write maintainers
for doing this, so we need an SC descision.  I'm about to send that.

Could you list the maintainers that thought this was a good idea?

You might be thinking that I thought this was a good idea, for instance, and at present I am not convinced.
I said 'seems' for a reason. At the summit, and after this recent design,
there were comments along the lines of 'wouldn't this be simpler/better in
C++/java?' And, not in the sense of 'of course it would be!', but
in the context of 'and why don't we just do that'.  first time round (at
the summit) I couldn't tell how serious that was, second time around it
appears more serious.

If I've misrepresented those maintainers, I apologize. If I've not,
perhaps they could comment.  The comments so far were made in informal
contexts, and I did not represent them in my propsal to the SC.

The technical points were,
Dan Jacobowitz gave me an idea about how to avoid a macro mess, but
at the expense of quadratic number of RECORD_TYPES for trees
when compiling gcc itself (but removing from same a linear static
type checking cost).  If this turns out to fly, we won't need
another little language (yay! thanks Dan)

Geoff, the rest of your comments are insightful, but in details that
I don't want to get into right now.  Can we revisit it after the 'big
picture' is dealt with (C++ or different structs).

Ian Lance Taylor wrote:
> That's not the argument, it's the strawman.  The argument is that once
> we are using a subset of C++, there is a very low barrier to using
> other parts of C++.
Yes, exactly.  I nearly started enumerating how all the other bits
of C++ might turn out to be useful!

> I'll repeat that if we are really going to switch languages, it would
> sure be nice to switch to one which supported garbage collection,
> instead of carrying around our own GC machinery.  I'll admit that it's
> easier to convert to C++ incrementally than it would be to any other
> language.
and then add GC to C++ itself?


Nathan Sidwell    ::   ::     CodeSourcery LLC    ::

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