> Both parse SQL, and there the similarity ends. The dialects are
> necessarily different. The GPRE parser has to deal with host language
> expressions that the DSQL parser doesn't. They have different error
> handling. They generate different data structures. The GPRE parser
> also handles GDML, which the DSQL parser does not.
>

Granted GPRE needs to deal with things like cursors and INTO clauses
that DSQL doesn't but surely that could be handled by creating a
generic SQL parser class and deriving DSQL and GPRE specific
subclasses from it. As for GDML, outside of the build process, is it
really used for anything anymore? In fact, I had to add a command
line option to GPRE to suppress recognition of QLI syntax (how, or if,
that is related to GDML is a bit of a mystery to me) because the QLI
keyword list intersects the Cobol reserved word list.

From the little enthusiasm GPRE stirs up in the various Firebird
groups one is left with the impression that embedded SQL is almost
extinct. I would have to assume that GDML is moreso.

> GPRE uses a hard coded, recursive descent parse. DSQL uses

yacc/bison.

> It would be better, far better, if DSQL also used a hard coded

recursive

> descent parser, but that's a different issue.

I'm not even going to try to argue the merits of different parsers.
I'm not remotely qualified. I always use hand coded recursive decent
parsers myself but that is largely because I've been doing it that way
for 30 years and I'm too lazy to learn how to use bison and yacc.

>
> Parsing is a trivial operation. It is far better to have a parser well
> integrated into the environment that it serves than to try and force a
> single parser into radically different environments.
>

Parsing IS trivial and perhaps it is better to have hand crafted
parsers specific to the particular environment. How then can we make
it easier to keep GPRE and DSQL in sync? To say that parts of the
code in GPRE are a bit opaque is putting it mildly.

People who need to use embedded SQL (like me) are coming off second
best because we don't get to use the new SQL language elements. I
guess I'm a bit luckier than most because if the need gets desperate I
have to skills to dig into GPRE and hack in the features that I need.
But it reflects poorly on the product as a whole to have different
feature sets depending on how you write your programs.

On the other hand, maybe I'm the only one who cares about GPRE anymore
because I have a huge legacy Cobol application and have no other
practical way to write database applications using Cobol. And, no,
converting it all to something else is not a realistic option.