Direct, language-native client-side parsing for Firebird-flavored DSQL appears
to be missing from most external open source libraries at the moment.
This seems like it is sometimes a hurdle in tool and framework integration of
Firebird, and I think this boils down to the direct integration of C++ parse
node code in the btyacc rules of parse.y.
I'd like to do something about this situation if I'm able. I have it in mind to
lift C++ code generation to a separate phase after the btyacc run, and through
the existing btyacc rules generate something more implementation-agnostic for
use in that later phase.
If I'm successful, I'd be pleased if it turned out to be usable by the official
project with minimal friction.
For that reason I am interested particularly in the views of core maintainers
about this topic, as well as references to particularly relevant past
discussions or issues in the tracker that might have been easy to miss.
I'm not certain that I'll be successful in my endeavor, but maybe future
readers could find this thread informative if they decide to pick up the
gauntlet.
A few sets of related questions come to mind initially:
1. (applicability & value)
- Do you view some change to this situation as desirable?
- Are you satisfied with the current situation of the DSQL parser and its
generator? Are there particularly sore points in its maintenance? Perhaps you
have a longstanding mental list of how things could be improved there?
2. (drawing on long-term experience)
- I have seen some old threads (for instance "BTYACC" starting on Dec 4, 2004)
where pros/cons of different types of parsers and parser generators were
discussed in the context of porting/migration to btyacc.
To any who were there: in hindsight, have your views on this subject changed
significantly? was the switch a complete net gain?
3. (build dependency-related questions)
- Would adding an additional build dependency be a significant, unconditional
barrier to adoption in the official source?
- What criteria are most important in choosing to adopt new build dependencies
for the project? I wish to keep my options open as much as possible here.
I imagine that a full python interpreter is not desirable as a build dependency.
What about, for instance, a minimal C-embedded Lua interpreter?
A bespoke tool written in an existing C/C++ library? (I see that
Boost.Preprocessor is currently included in the source)
- How much would it matter if such a dependency required an additional build
step, like CLOOP and btyacc?
other related comments and advice are of course welcome
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
