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

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

--- Kyle Lahnakoski <ky...@ar...> wrote:
> 
> I will mostly repeat what you said so that I know I understand.
> 
> James Michael DuPont wrote:
>  > the second step will be to document the meta-model in terms of the
>  > common lisp object system CLOS. it is a well understood model that
> has
>  > well defined semantics. I thik that a CLOSGenerator (Like a
>  > java-generator) is the right way forward.
> 
> CLOS may be very good MOP (Meta-Object Protocol) to copy.  It may be
> too 
> flexible; being needlessly complex to handle situations never used. 
> I really do not know much about the CLOS.

Well, I am just learning about it myself. We dont need to support all
features,
just the core set of them that we can. 

Classes, members, methods, collections.

The point is the CLOS interface will allow our data to be used in the
world of LISP/AI, and hopefully later even emacs.

By supported a simple CLOS export, we will also document our model to
other people in a language they understand. I think that defining our
model in terms of a more well known model will be easier that defining
our model in isolation.

> 
>  > But we need to do one more thing :
>  > Thirdly. all the language generators currently describe classes,
>  > the java generator creates classes. but what about objects?
> 
> I am sure that this is not a problem for CLOS.
> 
> It is not a problem for Java either; the reflection API is sufficient
> to 
> create objects and populate their fields.  We may want to add a
> simple 
> API on top of it for some more-commonly used operations. (assuming 
> anything is even built in Java)

Good point :

We have a java api generated now. Based on the introspector meta-model
we create classes, methods, members, inheritance and interfaces. 

The collections and containers to handle relationships between
containers and components is next : For example as we chatted about the

> 
>  > we nee an JavaInstance generator : the ability to create code that
>  > represents instances of java, in terms of the generated classes.
> Also
>  > we need to be able to read in instances from an XML/RDF feed.
> 
> So, I guess you are saying we need a standard MOP, probably like
> CLOS. 
> This standard MOP should be able to handle the majority of languages 
> introspector plans on inspecting.

The mop interface will be written in a high level language, based on
RDFS DAML. 

I hope to defined  with you a set of predicates that are avaiable 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. 

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.

Some of the gcc model definition in the type_overview are very hard to
read, they are extracted out of the xml, this will be replaced by the
rdf reader, so we can specify the class model in a C++ file and extract
it into rdf via the introspector.

> 
> Will this standard MOP will take the form of a document that humans
> can 
> read? 

yes. 

> Or are we going to have it hidden in implementation code?  :)
> 
>  > so to summarize :
>  >
>  > 1. support the creation of meta-model from the rdf input from the
> gcc.
>  >  : meta-circularity
>  >
>  > 2. support the generation of CLOS classes
>  >  : using a well defined class model to document ours
>  >
>  > 3. support the generation of source code for instances of
>  > Java, perl, CLOS, sql from the rdf, in terms of the generated
> classses.
>  >   : creation of literal source code that creates instances from
> the
>  > literals (constants)
>  >
>  > 4. Support reading of the rdf files and generation of these
> instances
>  > as programm code.
>  >   : creation of source code that creates instances from a variable
> file
>  > of data.
> 
> So introspector plans to:
> 
> 	Read in nodes from gcc
> 	Build an internal representation (functions, and classes)

> 	Serialize to various languages

yes, that is *ONE* major application of the introspector,
other people dont want to serialize, but to do analysis of the nodes.

so that looks like :
* 	Read in nodes from gcc
* 	Build an new internal representation (nodes and edges in a graph)
* 	Apply graph transformations
*       Generate reports.

or even :
* 	Read in nodes from gcc
* 	Build an new internal representation (nodes and edges in a graph)
* 	Apply graph transformations
*       Run nodes via graph layout tool VCG
*       Generate UML nodes in DIA
*       Export data into emacs
*       insert click handler in dia to open up emacs

> 
> In essence we will have a language conversion facility.
yes at the lowest level.
> 
> 
> 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.

for the building of the framework, yes, language transformations are
important. But that is just one step of many.

mike
> 
> 
> Thanks
> 
> 
> 
>
----------------------------------------------------------------------
> Kyle Lahnakoski                                      
> ky...@ar...
> (416) 892-7784                                    Arcavia Software
> Ltd
> 
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Introspector-developers mailing list
> Int...@li...
> https://lists.sourceforge.net/lists/listinfo/introspector-developers

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

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