Visitors and maps. In my C++ compiler architecture I have used visitors and maps. The AST just contains the basic term nodes, which then get annotated by type inference. Each pass is implemented as a visitor over the AST tree that maintains its state in a map private to the visitor object (which can be a reference in the case of state shared between several passes) from node-address to local state.
You can do something similar by giving each node in the AST tree a node ID. The AST structure is encoded directly in the tree, but different kinds of metadata can be stored in a map from node-ID to datatype. This way you can keep metadata local to the code that uses it. Keean. On 21 May 2015 00:56, "Matt Rice" <ratm...@gmail.com> wrote: > On Wed, May 20, 2015 at 10:44 AM, Jonathan S. Shapiro <s...@eros-os.org> > wrote: > > I've just noticed a problem in my previous AST/MetaAST question, and it > > *appears* to me that it forces one of the outcomes rather than the > others. > > > > The variant portion of the AST node is typically expressed as a GADT. The > > general idea is that if we know a parent node we know what it's child > nodes > > are supposed to be. So, for example, we have something like: > > > > type AST = > > ... > > and Expr = > > | MulExpr of Expr * Expr > > > > > > so far, so good. But now suppose that we want to carry position > information > > with every AST node. We appear to have two choices: > > > > 1. Add a Position field (or in the more general case, an ASTMetaData > field) > > to every tuple on every AST. > > 2. Stop checking the tree coherence statically, and instead do it > > dynamically. > > > > The second approach would force us to do something like: > > > > type AST = > > ... > > and Expr = > > | MulExpr of AST * AST > > > > where there is a known relationship between the parent node type and the > > allowed child node types, but we don't attempt to capture or check them > > statically. This is basically what BitC v0 is doing with ASTMaker. We > > describe something similar to a GADT in ASTMaker, and generate a sanity > > checking function that runs over the AST. We could also (but currently do > > not) generate "builder" helper functions to check that the tree is > composed > > correctly. > > > > I can do that, of course, but it seems inconsistent with the spirit of > > things. > > Indeed, this is about where I threw in the towel and just duplicated > ASTMetaData across the legs of the AST, going along with the > statically checked AST spirit of things > > > Last option, which I think does not really work, and cannot really be > done > > in F#, O'Caml, or Haskell, is to exploit the fact that a union leg type > > actually *is* a type, and use parameterization. I don't have a way to > > syntactically express this in these languages, but the general idea is > that > > the metadata node and the AST type would be mutually recursive types, and > > the metadata node would be of the form MetaASTNode<LegType-or-group-type> > > I'd think O'Caml and SML can probably do so using functors, not sure > about doing so elegantly or if priorities justify it... > _______________________________________________ > bitc-dev mailing list > bitc-dev@coyotos.org > http://www.coyotos.org/mailman/listinfo/bitc-dev >
_______________________________________________ bitc-dev mailing list bitc-dev@coyotos.org http://www.coyotos.org/mailman/listinfo/bitc-dev
