Heck yeah! Free insight
-
I have a parser generator called Parsley[^] which I have not updated in a while. One of the neat things it can do is link several grammars** into several different parsers, and then link the different parsers it generates together so they can use each other to perform sub-parses. There are a number of advantages to this, including the fact that you can disambiguate grammar constructs by factoring them out over multiple grammars - since the parsers each have their own parse table, you won't have duplicate entries which causing ambiguity. But I just realized I could parallelize the code generation for it too wherein each different grammar crunching task runs its own CPU bound operation to create the parse tables. And it's easy. ** a grammar is a document that tells the parser how to parse something. Usually it's written in a variant of BNF or EBNF. I came up with all of this during a conversation about schizoaffective disorder. My mind is really funny sometimes. I think it helped that I've been doing so much async stuff lately.
Real programmers use butterflies
-
I have a parser generator called Parsley[^] which I have not updated in a while. One of the neat things it can do is link several grammars** into several different parsers, and then link the different parsers it generates together so they can use each other to perform sub-parses. There are a number of advantages to this, including the fact that you can disambiguate grammar constructs by factoring them out over multiple grammars - since the parsers each have their own parse table, you won't have duplicate entries which causing ambiguity. But I just realized I could parallelize the code generation for it too wherein each different grammar crunching task runs its own CPU bound operation to create the parse tables. And it's easy. ** a grammar is a document that tells the parser how to parse something. Usually it's written in a variant of BNF or EBNF. I came up with all of this during a conversation about schizoaffective disorder. My mind is really funny sometimes. I think it helped that I've been doing so much async stuff lately.
Real programmers use butterflies
Interesting Can you elaborate a little on how to decide when to activate one (or more) of the (sub?) parsers? Of course you can activate a number of parsers simaultaneuously on a given input (sub)string Long, long time ago in one of the compilers we used a mix of bottom up and top down (recursive descent) parsers, is that (more or less) similar to what you are describing?
-
Interesting Can you elaborate a little on how to decide when to activate one (or more) of the (sub?) parsers? Of course you can activate a number of parsers simaultaneuously on a given input (sub)string Long, long time ago in one of the compilers we used a mix of bottom up and top down (recursive descent) parsers, is that (more or less) similar to what you are describing?
Member 12982558 wrote:
Can you elaborate a little on how to decide when to activate one (or more) of the (sub?) parsers?
The share a symbol table, so when you reference a symbol from a foreign grammar it invokes the subparser like here's an excerpt of a grammar i wrote:
/ SlangStatement.xbnf
// This is the XBNF spec for Slang Statements (gplex version - unicode enabled)
// Slang is a CodeDOM compliant subset of C#
@import "SlangExpression.xbnf";
// Statements// we use this with our skipped lists to get comments on to relevant nodes
Comments; // { lineComment | blockComment }
Directives; // { directive }VariableDeclarationStatement= varType Identifier "=" Expression ";" | Type Identifier [ "=" Expression ] ";";
Here I bolded the import line which will cause this parser to reference the SlangExpression parser generated by SlangExpression.xbnf (a grammar like this one) I also bolded all the foreign symbols. These invoke a subparse when encountered
Member 12982558 wrote:
Of course you can activate a number of parsers simaultaneuously on a given input (sub)string
I think maybe I wasn't clear about where the parallelization opportunity is. It's in the generation of the parser source code from the grammars. That's what I can make parallel. It means faster dev cycles for the parser because it doesn't take as long to generate. ETA: but i could parallelize the backtracking. Not sure if I would gain or lose perf doing that though
Member 12982558 wrote:
Long, long time ago in one of the compilers we used a mix of bottom up and top down (recursive descent) parsers, is that (more or less) similar to what you are describing?
It sounds like it. Here's I'm assuming your parsers call other parsers like the top-down delegates to the bottom-up for some things. If so, this is like that except it's all top down, not several different algorithms.
Real programmers use butterflies
