One of the things I plan to bring back in BitC is pattern matching. I personally do not like pattern matching, because it doesn't scale well syntactically as the number of fields in a structure rises. That having been said, it's a useful construct, and especially so when we start thinking about comprehensions.
My question here is: should mixfix constructs be admitted into pattern matching when they wrap a constructor? It's very easy to notice that the RHS of a mixfix binding is a constructor name. When this is true, it's pretty easy to admit the mixfix construct in both types and patterns. Conceptually, mixfix rewrites are purely syntactic, and they occur before type checking, so one view of this is that pattern analysis is performed by the compiler after the phase in which mixfix rewrites are performed. The modification to the compiler is simply to invoke the mixfix engine while parsing types, with some flag that restricts the elligible rule set to mixfix rules that wrap constructions. I actually have a reason for considering this, though it may not turn out to work. For the moment, all I'm trying to ask is: 1. Does this description make sense, and do we agree that it's doable? 2. Assuming it's doable, does it seem desirable? Oh. This would limply that some mixfix operators are not expressions: mixfix list@of_ = list Is a type constructor, but not a value constructor, because the /list/ on the RHS is a type constructor but not a value constructor. Oh. And note that this introduces a new wrinkle in the operator precedence discussion: (list (of char)) // Following the curried intuition list@of char // Becuase list@of is a two-identifier mixfix construct shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
