|new compiler metadata... firstname.lastname@example.org (cr88192) (2009-05-24)|
|Date:||Sun, 24 May 2009 13:18:45 -0700|
|Posted-Date:||24 May 2009 19:43:29 EDT|
well, anyways, maybe people here might be interested or have comment.
so, basically, I ended up eventually adding a "repository" for metadata, and
not quite what I had originally imagined. at first, I thought I would
implement a relational-database style structure, but this seemed like it
would be too awkward in general to work with, and so I never really got to
eventually, I had ended up hacking a prior key/value system of mine, and
modified it to store the metadata (mostly by embedding a bunch of info in
the key name, and using it to fetch the value). however, this approach
produces long strings and so wastes lots of additional memory.
a more recent change had been to go over to an essentially heirarchical
structure, where a 'path' is used to address a group of key/value pairs
(note that a path may contain both key/value pairs, as well as sub-paths,
and each path has a "default" key as well, I represent in storage as '_').
note that I only made minor alterations to the original interface, which
primarily accesses metadata by fetching and setting keys.
this metadata is not used so much during compilation (the compiler keeps its
own data), but is more present so that the runtime is able to figure things
out (especially useful for automatic code generation tasks, managing the
object system, ...). the compiler actually primarily runs and produces 2
forms of output: RPNIL, which goes to the lower compiler stages; and
metadata, which goes into the "metadata repository".
this kind of information would also be likely stored when compiling a
library (stored along with the object modules), and would serve a role
loosely similar to a header file (only, not needing a proper compiler to
parse, more just loading the library into the current program image...).
I am just wondering if people think this is interesting, or at least
"adequate", or if it is really justified to go over to using a more
elaborate structure (namely, a combination of a heirarchy and a relational
database...). actually, I may go and implement such a database system, but
unless needed will probably not use it for compiler/runtime metadata (or,
unless I can figure out a really convinient API for managing operations like
inserts and queries, which IME are generally awkward...).
so, for examples (these are from the external cache, which is a textual dump
of the repository):
here is a struct:
and a few functions:
and a type declaration followed by a struct:
Return to the
Search the comp.compilers archives again.