This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
RE: Using of parse tree externally
- To: 'Lee Iverson' <leei at Canada dot AI dot SRI dot COM>, Mark Mitchell <mark at codesourcery dot com>
- Subject: RE: Using of parse tree externally
- From: "Dupont, Michael" <michael dot dupont at mciworldcom dot de>
- Date: Fri, 20 Oct 2000 10:11:39 +0100
- Cc: "Dupont, Michael" <michael dot dupont at mciworldcom dot de>, gdr at codesourcery dot com, espie at quatramaran dot ens dot fr, gcc at gcc dot gnu dot org, unrev-ii at egroups dot com
Lee,
I just took a look at the CSF2-DTD,
http://sds.sourceforge.net/doc/csf2-doc.html
It would be possible to extend the code that I have been working on to
include a backend for CSF,
and that is exactly the type of information that can be provided from the
Introspector (the name that I thought up for the compiler interface).
You will find in the Derived Nodes a few derived classes for adding user
functionality for what you want to do :
I only have the c-parse worked out right now, so bear with me
modules become packages and structs become classes.
One would have to add the functions to the following classes to map on the
the CSF dtd :
CLASS ---> maps on to ENTITY
record_type_TreeRef_D --> class
parm_decl_TreeRef_D --> arg
the functions become methods in a package :
function_decl_TreeRef_D --> method
does a type_decl map onto a typespec, I dont know.
D_type_decl_TreeRef --> typespee??
and so on and so on.....
So,
If one made a base class for all CSF output
and mixed those functions protoypes into the derived classes for the
different classes,
then you can make an output for CSF from the gcc compiler.
If you have new classes that are not handled,
you can register you own classes to be called back via the array of
factory functions
eg :
"
CREATEOBJECTS[FUNCTION_DECL]=function_decl_TreeRef_D::FactoryCreate;"
This registers the static member function FactoryCreate
TreeBase * function_decl_TreeRef_D::FactoryCreate(tree_node* pnode)
{
return new function_decl_TreeRef_D(pnode);
};
You can either create a new set of classes or add member functions to the
ones that I have provided.
What do you think?
Mike
-----Original Message-----
From: Lee Iverson [mailto:leei@Canada.AI.SRI.COM]
Sent: 19 October 2000 19:48
To: Mark Mitchell
Cc: michael.dupont@mciworldcom.de; gdr@codesourcery.com;
espie@quatramaran.ens.fr; gcc@gcc.gnu.org; unrev-ii@egroups.com
Subject: Re: Using of parse tree externally
[I've cc'ed this to the unrev-ii@egroups.com mailing list. For those
of you seeing this there, this is a response to a discussion of a
suggestion to provide XML output of the parse tree created by the GCC
compiler suite. -- leei]
In message <20001019082036K.mitchell@codesourcery.com>, Mark Mitchell
writes:
>>>>>> "Dupont," == Dupont, Michael <michael.dupont@mciworldcom.de> writes:
>
> Dupont,> Hi Marc, Gaby.
>
> Dupont,> I am still thinking about how I am going to publish my
> Dupont,> work properly.
>
> Dupont,> The work that I have done so far is :
>
>The mode that would be most interesting would be dumping the tree
>nodes as XML. That facilitates a lot of things.
It certainly does. It is of course the easiest way to enable almost
all of the *dangerous* possibilities being discussed.
Another tactic would be to only dump cross-referencing info in XML.
One of the greatest difficulties we have in discussing and documenting
software is the difficulty in linking those documents to the source
code in a meaningful and transparent manner. Consider the usefulness
in having a means of publishing sources in a form whereby it is
trivially possible to navigate from source to documentation to
discussion and back. We'd potentially be able to combine the
advantages of literate programming, cvsweb and structured external
documentation to hopefully make all of our jobs easier.
Why does there need to be compiler support for this? Well, for C++ at
least and inhertance-based object-oriented languages in general it can
be extremely difficult to accumulate good cross-referencing
information external to the compiler. You just have to duplicate too
much of the compiler's work.
Where am I going with this? Mark knows. If we can come up with a
decent, flexible, language-independent XML DTD for source-code
cross-referencing then we can dump this information from the compiler
and build other tools to allow use to fully XMLize the sources with
this cross-referencing info. Given that, we'd have a way to
incorporate actual sources directly into discussions and documentation
via hyperlinking.
There are open sourcce projects that are moving in this direction.
The SDS (http://sds.sourceforge.net) is definitely moving in this
direction, and they'd benefit greatly from such an effort.
Of much more potential long-term benefit is the Open Hyperdocument
System (OHS) project being led by Doug Engelbart (see
http://bootstrap.org, the unrev-ii list on http://egroups.com and
http://ohs.sourceforge.net) which is about collaborative document
management and community building. The targeted bootstrap strategy for
the OHS group places the augmentation of open source software
development at the core of its mission.
Anyone else interested? I know Mark Mitchell and I are.
----------------------------------------------------------------------------
---
Lee Iverson SRI International
leei@ai.sri.com 333 Ravenswood Ave., Menlo Park CA 94025
http://www.ai.sri.com/~leei/ (650) 859-3307
--
This communication contains information which is confidential and
may also be privileged. It is for the exclusive use of the
intended recipient(s). If you are not the intended recipient(s),
please note that any distribution, copying or use of this
communication or the information in it is strictly prohibited.
If you have received this communication in error, please notify
the sender immediately and then destroy any copies of it.