I see value on it, but the task seems not easy. First, let me say about problem in current parser (not only the parser):
It does not recover from errors and continue parsing (and doing semantics analysis) to show all errors. It stops on first error. This is very bad. I'm not saying it is impossible to do with btyacc. It's probably possible. Then you are saying to integrate the parser in another tools. Then, probably btyacc is not the way to go. Nor python tool. What seems very well supported in multiple languages is antlr. I already worked with it (not with Firebird language). Antlr has a good concept for write a language and use it differently in differently contexts (client or server). But it's not easy to use. With btyacc we just return nodes. With antlr, at least in the more common way to work, we should build a visitor which makes things much more complicated. Also, especially the Windows guys generally do not like new dependencies. And if you said Java, it is going to complicate things even more. So I see a value and I think it's more viable to start it as side project initially for client tools. It's bad that will require duplicated efforts to mirror the official syntax. Adriano On 13/10/2020 00:15, Arily Essen via Firebird-devel wrote: > 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 Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
