D Parsing (again)/ D grammar

[Philippe Sigaud via Digitalmars-d]

> 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.