This is actually the "dual" of my previous question. Assume that we're writing code to walk an AST tree. We know that the first child of an "if" AST needs to be an expression. That might be one of several AST types, but conversely it cannot be certain *other* AST types.
Assume further that we *don't* have anything like match type. It seems to me that we end up writing a bunch of CASE statements. We have a *useful* case-leg corresponding to each of the legal expression AST types, and then we have a catch-all DEFAULT leg that does error handling (presumably raising an exception, since this would mean that the AST tree was malformed). There are two misfortunes here. The first is that we are going to carry some code that throws exceptions that we should (by construction) never hit. The second is that in consequence we're going to pull in the exception support subsystem, which can be a fair chunk of code. In a compiler we'll have exceptions anyway, so that's not a compelling problem, but in an operating system kernel that's code we really don't want. Q: lacking match type, is there an idiom that would allow us to see that this code can be dropped? The second is a BitC thing. BitC has a current notion of "leg intersection" union cases. The idea is that unions very often have the same field in the same place in some legs. For example a union of capability structures will tend to put the "object ID" field in the same position in all legs that actually *have* an object id. BitC has toyed with a construct where you can say: "I want these three union leg cases to go through this path, where I plan (and the compiler will require) to examine only those fields having the same position, name, and type in all of the legs I have mentioned." There are a surprising number of cases where this is actually useful. The thing is: you have to be able to name the leg types you intend to be considering in the CASE leg syntax. For things like "expr" nodes, that's a lot of cases and it would be nice to be able to define the set somewhere and be able to reference it. Hmm. That's not such a big misfortune, is it. In fact it's pretty immediate how to go about it... Maybe I need to ponder this some more. shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
