I have been thinking hard about the problems of mixfix. Not so much the parsing as the potential for confusion. I have a hair-brained idea, and I want to float it so we can shoot it down.
We can view mixfix as adding and removing things from the language grammar as the parse proceeds. It seems to me that the main problems with mixfix are: 1. mixfix does not properly respect scope; it is promiscuous and invasive 2. it is surprisingly easy to build two mixfix sub-grammars, each of which is okay in isolation, that are ambiguous when taken together. 3. there are very active debates going on about how precedence should be handled. It seems to me that all of these issues are *relatively* straightforward, and the core of the problem is that mixfix is not a well-conceived syntactic mechanism for introducing specialized sub-grammars. Here is alternative that seems to me to address many of the issues that MarkM has identifier. First, we introduce a construct for describing *named* sub-grammars. These are constructed in the usual way that we are all familiar with. A sub-grammar introduced in this way may involve multiple productions, the first of which is the "start" production w.r.t. that sub-grammar. Defining a sub-grammar does not implicitly cause that grammar to become active for parsing purposes. Second, we introduce a syntactic form: with syntax <grammar-name> <expr> with the intended meaning that the named grammar defines *all* infix/prefix/... notation that is live in <expr>. Third, we introduce a second syntactic form: use syntax <grammar-name> with the intended meaning that the start production of <grammar-name> should be merged with the currently active start production (it is an error if this results in ambiguities). The preamble would issue "use" statements for the customary grammars of arithmetic and boolean expressions. Each sub-grammar is viewed as defining a *partial* order on operators, and the test for "merging" two grammars is to see if the combined set of inequalities from the respective top-level productions fails in some way. Part of the notion here is that a sub-grammar is acting in part as a scoping construct for parsing. There is a good bit more mechanism needed to actually make this sort of thing work, but it currently smells to me like something along these lines might be workable. If so, would something along these lines address the major concerns about mixfix? Yes, this proposal requires that people introducing new syntax actually put in some design effort. I tend to view that as a *good* thing. shap _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
