[bitc-dev] thoughts on mixfix
Jonathan S. Shapiro
shap at eros-os.com
Wed Mar 11 12:02:50 EDT 2009
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
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
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
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
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*
More information about the bitc-dev