3 ms·
That's more or less what I meant by "priority graph" in the article: priority is defined using a directed acyclic graph. In principle, yes, you could have a way
by breuleux 12y ago
That's more or less what I meant by "priority graph" in the article: priority is defined using a directed acyclic graph. In principle, yes, you could have a way to add new nodes in the graph; you don't really expect n to be large in this case.
Parsing wouldn't necessarily be very complicated. An operator precedence grammar[1] can be fully implemented in about 50 lines of code. If you run a simple sequential algorithm, completed expressions could be executed immediately and could modify the precedence matrix dynamically. You do lose, however, the option of parallel parsing.
There's an idea I am toying with, though, which is to split source files in "zones". A separator, say, "=====", would act as a hard delimiter for parts of the file. The first part could define the syntax of the second part, etc.
[1] http://en.wikipedia.org/wiki/Operator-precedence_grammar http://en.wikipedia.org/wiki/Operator-precedence_grammar
- TheLoneWolfling 12y agoAgain, you introduce context-dependance - which is something that you explicitly say you shouldn't have. What AST a <foo> b <bar> c is turned into depends on what priorities <foo> and <bar> are defined as. This starts to get nightmareish very quickly, at least if you're trying to leave open the possibility of compilation as opposed to interpretation. Zones are an interesting possibility to solve this, although it doesn't have generality - there's no way to express "zone C depends on zone B and zone A, but zone B doesn't depend on zone A, nor vice versa", for instance.
- breuleux 12y agoWell, the idea of zones is that the second zone depends on the first zone, the third depends on the second, and so on. It is meant to allow definition and use of a language within the same file, so there is little point in having a different dependency structure, I think.