Stephen Boyd wrote:

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

I turned the DSQL parser into a class in Vulcan. It's not going to get
you anywhere. Yacc is yacc and doesn't subclass.

GPRE and QLI are both instances of GDML.

It shouldn't make any difference that GDML keywords overlap COBOL
keywords. The GDML is long gone before it hits the compiler. That's
why it's called a preprocessor.

I hope the build process isn't using COBOL these days.

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

Every company and project that has used a yacc/bison parser for SQL
regrets it. The only good way to get rid of yacc/bison is to quit and
start another company. Just make sure you don't get bought out of a
company still struggling with bison. Sigh.

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

Hey, it was my first C program. Be nice.

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

Sorry, if I were smarter then, I would have used an OO API. The only
problem was that OO hadn't quite been invented then.

Add One to Cobol, anyone?

--
James Starkey, Senior Software Architect
MySQL Inc., Manchester, MA, USA, www.mysql.com
Office: 978 526-1376