Re: announcing synfl, the next generation of fontlock

>>>>> "Marcus" == Marcus Harnisch <[email protected]> writes:

    Marcus> I didn't spend much time looking at the code, but could
    Marcus> both parsers maybe share stuff? The fontification backend
    Marcus> could also be made modular to access either `semantic' or
    Marcus> `synfl' data.

I don't know.  I suspect it would be very hard to share backends,
because (a) semantic is based on eieio IIRC, while my objects are
homegrown, and (b) (unless things have changed fairly recently)
semantic is a top-down recursive descent parser with a well-defined
"product", while synfl is bottom-up with a huge amount of flexibility.
Or to put it another way, I haven't thought about it at all, so you're
on your own, whereas the semantic provides you with a reasonable
framework to hang your tasks on.  They definitely won't share
implementation code---I'm doing synfl in part for the sake of playing
with an LR parser, but synfl is nowhere near as capable as semantic
yet so they can't use it.

Also, I have a suspicion that semantic is somewhat constrained by the
need to support existing clients like JDEE.

    Marcus> Sharing the same grammar source would already be a great
    Marcus> thing to avoid having to maintain two grammars for each
    Marcus> language.

Well, this is stretching my expertise by a lot, but my understanding
is that we really do want to maintain separate grammars for each
parser.  For example, the grammars I use in my demos are all
left-recursive, which IIRC guarantees infinite recursion in a
recursive descent parser---they strongly prefer _right_-recursive
grammers.  For sure, the constructs that each is most efficient for
are different.  It might be possible to start with a "generic" grammar
for C and then tweak it for each parser, though.

More difficult---consider that many tasks are implemented with
syntax-directed definitions.  This means that the actions are embedded
in the grammar---but top-down and bottom-up methods will execute them
in different orders.

I really suspect that this is a case where we aren't ready to decide
on a particular schema for grammars, yet.  Friendly competition will
be good for both packages.

-- 
Institute of Policy and Planning Sciences     http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
               Ask not how you can "do" free software business;
              ask what your business can "do for" free software.