Gregor, It looks like we are going into a similar direction. I would like to make sure that we can represent this information in the parrot, if the compiler writers want to provide it.
--- [EMAIL PROTECTED] wrote: > James -- > > I'm open to other ideas. I've toyed with learning DAML and RDF for > some > ontology stuff I'm interested in, but so far I haven't had the mental > > "click" > that would make me feel comfortable working with them. I do have a > good > comfort level with XML in general. The click came for me was very simple : triples are simple. Rdf is simple. Tools are built to process graphs of triples. XML is more complex, xml gives you more freedom, less structure. here is an example stat64 * __statbuf; <#id-59> <node_fields:linenumber> "394" . <#id-59> <node_fields:filename> <#filename-stat.h> . <#id-59> <node_fields:type> <#id-24> . <#id-59> <node_fields:name> <#id-61> . <#id-61> <node_fields:strg> "__statbuf" . <#id-24> <node_fields:ptd> <#id-29> . <#id-24> <node_fields:size> <#id-28> . <#id-28> <node_fields:low> "32" . # the pointer is 32 bytes <#id-29> <node_fields:flds> <#id-35> . I have omitted the fields of the struct <#id-29> <node_fields:modifier> <node_modifiers:struct> . # it is a structure <#id-29> <node_fields:size> <#id-34> . <#id-34> <node_fields:low> "768" . #the struct is 768 bytes <#id-29> <node_fields:name> <#id-33> . <#id-33> <node_fields:strg> "stat64" . > I am pondering the sorts of transforms I could implement against the > XML > I've generated (using XSLT)... Yes, xslt is good. > > Another twist would be: can the compiler be reasonably implemented as > a handler for the SAX events generated by the parser? If so, then the > XML > I'm generating today is just a textual rendering of the actual data > structure > passed from the parser to the compiler. I'm thinking this might be > possible > since a good amount of the optimization will occur in IMCC. that is the idea behind the introspector, we extract the ASTs from the gcc before they get transformed to RTL. > Failing the pure SAX approach (which kind of implies single-pass), > the > other > possibility would be DOM (accept the SAX events, build a tree and use > DOM to tinker with it). These would be really good for the users. > > XML is not a religion for me, but I am interested in pushing on it to > see > where > the boundaries of practicality are. XML occupies the following slot > in my > map: > > A common way to render (annotated) tree structures (with > ordered children) as (mostly) plain text. > > (of course, you can substitute "graph" for "tree" if you consider > internal > links). > > Already, tinkering with the XML rendering of the Jako parse tree has > made > me think more deeply about a few of the language issues. For example, > I > need to treat strings with interpolations as expressions rather than > as > string > literals (I'm making this transformation on-the-fly in the > compilation and > SAX > rendering of string "literals" now, but it *should* happen during > parsing, > making the interpolated string C<"Howdy $what world!"> result in the > same > parse structure as C<'Howdy ' . $what . ' world!'> -- the former is > just > syntactic sugar). Sounds good. ===== James Michael DuPont http://introspector.sourceforge.net/ __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com
