Re: [Introspector-developers] Happy new year, plan for 2003

[James M. D. <mdu...@ya...>]

--- Kyle Lahnakoski <ky...@ar...> wrote:
> James Michael DuPont wrote:
> 
>  > The mop interface will be written in a high level language, based
> on
>  > RDFS DAML.
> 
>  From what little I can see DAML+OIL is the only standard relating to
> 
> class definitions (http://www.daml.org/2001/03/daml+oil-index.html). 
> But even this is quite restrictive (class algebras and attribute 
> definitions only).

Well they also support properties, and that is very important. 

The meta-data that we have about about the gcc nodes can be described
with such a ontology. Basically a complete set of all the predicates,
the types of nodes etc.

OWL also supports more methods, and cyc even more. 
cyc :
http://www.daml.org/ontologies/132
owl
http://www.w3.org/TR/2002/WD-owl-ref-20020729/

Ww should be able to define new predicates as need, 
have you any in mind?

> 
>  > I hope to defined  with you a set of predicates that are available
> to
>  > use in a RDF file that can be used as a resource in the future.
>  > Documented and related to other models. The whole trick is to
> produce
>  > files that we can build apon. That is one drawback of the current
> usage
>  > of perl hashes for storage in the introspector, there is too
> little
>  > structure and they are hard to interpret.
>  >
>  >  A set of predicates that are available. Right now that is the
> contents
>  > of the ModifyClasses and the Meta* classes.
> 
> Am I right to assume you are concerned that your existing set of 
> predicates may not be sufficient?  

No, I am concerned that we are covering the same ground as others. 

> Copying CLOS would provide a sense
> of 
> security that the necessary predicates are defined, despite not being
> in 
> use at this time?
I just want to map the clos predicates on to ours, in order to define
our model in terms of clos. We dont need all the clos. 

Because the clos is so mature, we should be able to learn from them,
and also copy needed interfaces that we dont cover yet.

> 
>  > We have that meta-model that is used to describe language
> structures
>  > dealt with. Then we have an instance of that that are extracted by
> the
>  > gcc into the input/types_overview and input/fields_overview and
> the
>  > CreateClasses.  These files define the gcc c,c++,and java model as
> an
>  > instance of a meta model. From there we translate the model into
>  > different languages, perl, java, sql, (treecc) etc. later also
> CLOS.
> 
>  >>Will this standard MOP will take the form of a document that
> humans
>  >>can read?
>  >
>  > yes.
> 
> Then I would be happy to at least start something.  I would prefer a 
> more UML-like notation over DAML/XML.  I am a more visual person than
> textual.

Ok, well, UML is great. I like UML. 
The plan was to export the model into DIA and be able to edit it in DIA
as well. Using VCG as the layout. We are not there yet.

> 
>  >>What language is this all written in?  Perl?
>  >
>  > right now, yet. The whole challenge is to defined a Java and Lisp
> based
>  > interface into this MetaData, and the instance data so that you
> can get
>  > a standard stream of program data from the gcc. What you do with
> it and
>  > how you process it is application specific.
> 
> Oh.  There are two problems Introspector may be solving, please
> indicate 
> which one:
> 
> 1)	If we want an MetaData interface to Java, Lisp, etc, then should
> we 
> just build the prerequisite classes in each that will read the 
> *.ntriples data and provide ability to tour the resulting objects
> (which 
> describe the program structure).  This option is dreadfully simple to
> do, but hard to extend.

Hmm, that is a idea. If you can create new java classes on the fly? 
I guess that is the idea. 

If anyone wants to create a java or lisp implementation that reads the 
rdf files and builds them into an intelligent model in memory, then
please do that. 

> 2)	We make a set of programs (in Perl) that write the MetaData
> interface 
> for each langauge (let's call these programs the "MetaClassWriters").
> 
> The MetaClassWriters are easily extensible because, presumably, they 
> read some common meta-class description.  Ihis version is harder to 
> write because of the meta-programming involved.  You appear to be
> doing 
> this now.
yes, I have a set of classes, JavaGenerator for example that will
output java definitions based on the meta data.

> 
> I am lost as to what the ultimate goal is.  Maybe I stop asking dumb 
> questions if you told me about some example program that would use
> this.

The goal is to provide a simple and easy to use API to the gcc ASTS in
many languages. To create a model of the internals of the compiler in
such a way that we can easily create applications that process them.
the number of applications are enormous. Just look at the different
project that you have SWIG, Doxygen, GCCXML, etc. there are many tools
that need this data, and we can provide it.

That idea is to be expanded also to cover other meta-data like from
Bash, I have been experimenting with bashdb.sf.net it looks like they
cover all the needed information, it should be easy to create an
interface into that.

The introspector as I said should be viewed as a Telephony Switch,
something that you hook your applications up to and you accept calls or
place them. The need is simple, many free software tools need to get at
meta-data, we should provide it.

mike

=====
James Michael DuPont
http://introspector.sourceforge.net/

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com