--- Dan Sugalski <[EMAIL PROTECTED]> wrote: > Since it looks like it's time to extend the packfile format and the > in-memory bytecode layout, this would be the time to start discussing > > metadata. What sorts of metadata do people think are useful to have > in either the packfile (on disk) or in the bytecode (in memory). > > Keep in mind that parrot may be in the position where it has to > ignore or mistrust the metadata, so be really cautious with things > you propose as required.
Dear Dan, I would like to see a powerful meta-data system made possible, even if it is not implemented immediatly. The symantic web researchers like David Beckett and Tim Bernard-Lee have been working on powerfull systems to support meta-data in general, maybe as the parrot meta-data is just getting started, we can cut a bit of that off? Take a look at the list here at Diffuse MetaData Interchange [4] at the bottom of this mail, you will see an overview of metadata systems. Even if they are not specific to parrot, the goals are similar in many casess. Recently I have been making progress with the rdf[1], specifically with the redland application framework[2]. With the simple concept of triples of data, a triple being (subject, predicate, object) we are able to capture the metadata of the gcc compiler, and I hope other compilers and systems. Redland is written in clean c, and supports meta-data storage in memory, and on disk in multiple formats, in rdf/xml, rdf/ntriples (even in berkleydb). It would be possible to create a new storage model to store the a packfile as well. The subjects are the items in the program, the node, each getting a number inside the system. Predicates are important, the represent the meat of the system. The objects are either literal data or other subjects. Via the redland api, you can add in new statements about things, and find all the statements about a subject, about an object, all that meet a predicate. I tell you this, because maybe you want to provide this sort of flexible meta-data api into parrot : for example the predicates that we extract that you might find interesting : * Filename of the node * Line number of the node (the Column Number is not supported yet) * Internal Type of the node (variable declaration, type, integer const, etc), as opposed to the type of the * Name of the node (the identifier) * Type of the node (if it is a variable, or constant) this is a pointer to another node * Unsigned Type of a type, if a type supports itself being unsigned, here it is. * Comments are supported, but not used yet, but would be a good idea. Now we get into more specific types of predicates * Parameters of an expression * Variables in a block * Size of a variable * Alignment of a variable * Constant flag * Volitile flag then we have * Fields of a struct * Parameters of a function * Return type of a function * Body block of a function So, with this idea of meta-data, by adding more predicates, you can support the capturing and storage of all the source code in an abstract form, or just the basic function data. You will probably think that this is overkill for parrot, but I think that it would give you an extensible system to add in new forms of meta-data as langauges are added. Via OWL[3] the users will be able to define the meaning and the classes of metadata as well. mike [1] RDF http://www.w3.org/RDF/ [2] Redland http://www.redland.opensource.ac.uk/ [3] OWL http://www.w3.org/TR/owl-absyn/ [4] Diffuse MetaData Interchange standards http://www.diffuse.org/meta.html ===== James Michael DuPont http://introspector.sourceforge.net/ __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com
