Re: Meta-Level Compilation project / Introspector/ AST access / Licensing question

[Joe Buck <Joe dot Buck at synopsys dot com>]

I'll only respond to one of James Michael DuPont's points.  I apologize
for wasting more of the gcc list's time, but someone is misinterpreting
what I wrote.

> My original question was if the MLC project is not a
> problem in the eyes of Joe Buck, then embedding any
> language interpreter should also not be a problem,
> then  making gcc a perl module is also not a problem.

[ MLC project: see http://hands.standford.edu/ ]

You perhaps misinterpreted my answer.  I see no problem with accepting
GCC patches to implement at least parts of the MLC project's functionality
in GCC, and I don't believe that such an implementation requires complete
modularization of GCC.  Evidently you differ, but such differences would
be resolved if and when someone submits a specific patch to implement
part of the functionality.  Until then we are arguing over a hypothetical,
as it appears that the Stanford group is keeping the code to themselves
and not distributing it at all.

I would be delighted to see GCC implement at least a subset of the
Stanford checker's tests, for instance reasoning about null pointers.
(The notion is that if you see "*p" the programmer believes that the
pointer is non-null; you propagate these beliefs over control flow paths
and look for contradictions).

This would not require anything resembling a complete program database,
any more than pass 2 of the old lint needed a complete program database.
In fact, I might suggest it for a GCC project.

Secondly, I reject your notion of argumentation from precedent.  Arguments
of the form that if we accept A, we must also accept B, may apply to a
court of law, but they don't apply to a software development team.  We
might like A but not like B, based on judgments more sophisticated than
can be represented in binary-valued logic.