On Mon, Jun 1, 2015 at 10:58 AM, Matt Oliveri <[email protected]> wrote:
> On Mon, Jun 1, 2015 at 12:09 PM, Jonathan S. Shapiro <[email protected]> > wrote: > > But I don't even see a good solution for CFGs, because of the "subunion" > > issue. I know how to deal with that using dynamic checks, but not > > statically. > > I guess I don't see why subunions are important for ASTs for CFGs. It > seems to me like unions of unboxed tuples are good enough. Subunions > would additionally guarantee the use of the same tag for the same leg > in all subunions of a given union. But why is that so important? And > of course, those unboxed tuples being unboxed is an optimization. It > still works if they're boxed. So first, you're right. We can build a perfectly good AST structure without any sort of subunion construct, and the subunion construct may not have enough use cases to warrant introduction into the language. Even if it *does* warrant inclusion, subunion may not be the right mechanism for capturing this. There are two reasons to consider something like a subunion construct. The first is that it gets us just a little bit closer to expressing the actual tree construction constrains: "in this place we should only have these kinds of children". The second is that it justifies us in leaving cases out of the CASE statement when we dispatch over a given child node, because we know those cases cannot arise. But note I am assuming here that when this is all over we want to have a single ASTNode type. Your threading solution suggests an interesting alternative: rather than make all node types homogeneous, use different node types to capture different cases. Believe it or not, it's an approach that I simply hadn't considered. There are pros and cons to both approaches. The style of the AST walking passes in BitC tends to be "big switch that runs in recursive-descent fashion". It often turns out that there is useful common code at the top of such procedures, but it is also true that many nodes are "uninteresting" in any given pass. It might well simplify the passes a bit if some of the cases were broken out by type in more or less the way that your approach implies. I think what I'm saying is that subunions are *not* necessary to solve the problem, but may simplify certain kinds of recursive descent code. You've certainly weakened the case for subunions (which is good!), and I now want to think about the choices I made concerning my AST type. shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
