> I have a huge collection of projects I never published :-) We all do, I > guess.
Oh, the ratio is more and 100 projects for one published... > No, this is not exactly what I mean. Multithreading can be perfectly fine in > some cases, very fruitful sometimes. Say, in NLP, when one has to process > long or highly ambiguous strings, and the parse tree can become huge and is > of importance in itself... Yes. In programming language parsing this is just > a small step towards further stages within a longer pipeline. It has to be > fast enough to make multithreading on this step an overkill. I don't know. Using fibers, I'm hoping to get interesting results one day. I got it by a workstorm before trying fibers. OS threads were a bit to heavy and didn't work that well. > BTW, there's one an interesting related work that probably should be taken > as a positive example of generalized parsing: the Elkhound parser generator. > It uses a hybrid LALR/GLR approach, thus achieving better performance. > There's much more to it, I didn't go too deep into it. Yes, Elkhound is interesting, their approach is nice. But It gave me the impression to be abandoned for a few years? > >> I found an article by the GLL authors explaining how they coded their >> algorithm for more speed, but I couldn't wrap my head around it. > > > By now, I have read the original Tomita's GLR paper, Antlr ALL(*) paper, a > few recent GLR papers, three papers on GLL and a few related ones . It > took... A while. I sort of understand the idea, but still not sure about the > details :-) ALL(*) is on my todo list. I tried to implement it in Spring, but got bogged down in the details. Even the white paper has some imprecisions when you really sit down and try to code it. I could have a look at ANTLR v4 source, but wanted to have a clean start, right from the white paper. > What's the name of the paper you read? "Modelling GLL Parser > Implementation"? Yes.
