4 ms·

Here's an interesting way to do operator priority: Specify priority relative to other operators, including associativity, and let the language figure it out. I

Here's an interesting way to do operator priority: Specify priority relative to other operators, including associativity, and let the language figure it out. If something is ambiguous or inconsistant, emit an error. The nice thing about this is that it removes the entire concept of "first-class" operators. If you want to inter-operate with something, specify the relative priorities as needed and you're done. The down side is that the worst case time to detect cycles is O(n^2) with the number of operators, at least if you include the relative priority of '!='. Although, that being said, I'm not sure if it's a good idea to include '!=' as a relative priority. It also means that your parsing becomes... less than amusing. In particular, it suddenly becomes rather context-dependent. This breaks one of the "laws" described here. Still something interesting to muse about, however.

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 ago
  Again, 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 ago
    Well, 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.

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 ago
Again, 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 ago
  Well, 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.