Re: SQL pre-processor (was RPG IV release levels and complexity)

[Hans Boldt <boldt@xxxxxxxxxx>]

Joep Beckeringh wrote:
> Jon and Hans,
>
> You are both referring to an 'old debate' and 'current architecture' and an
> 'alternative architecture'. I don't know about the others on the list, but
> to me the whole discussion is rather meaningless without knowing what these
> terms refer to. Would one of you (or both of you) care to explain?

The "old debate" had been simmering for years.

The "current architecture" is where there's a separate preprocessor that 
reads SQLRPGLE source and outputs an RPGLE source member, which is then 
compiled by the RPG compiler.

One "alternative architecture" was defined by the OS/2 Database Manager 
back in release 1.2 (or thereabouts). In that architecture, there was no 
separate prep phase, and the compiler invoked DM API's to handle the 
embedded SQL. There were four API's to be called by the compiler, for 
initialization, termination, defining host variables to SQL, and for 
compiling individual embedded SQL statements. The advantage to this is 
that SQL doesn't need to write multiple preps, and only has to deal with 
issues specifically related to SQL.

But, and this is a big *BUT*, in this design, there are cases where the 
compiler writer has to understand certain aspects of SQL syntax /and/ 
semantics. And so the onus is put on the compiler development team to 
keep up with SQL, rather than the other way around. As elegant the 
architecture may be, the logistical consequences are unacceptable for 
both the compiler development team and for the SQL team.

. . .

But to divert into the realm of "wild and crazy ideas", apart from SQL, 
the thought occurred to me that it might be possible to add some 
framework into the RPG compiler to implement a sort of generalized 
processing of 3rd party embedded statements. That is, if you coded 
something like "exec xyz ...;", exits for component "XYZ" would be 
invoked which would return RPG statements to include in place of the 
exec statement. Anyways, I seriously doubt if anything will come out of 
such flights of fancy since it would need a lot of work in the compiler, 
but it's fun to imagine the possibilities.

Cheers! Hans