[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Macros Make Me Mad

   It's not because of macros, but because it has a SQL sublanguage
   integrated deeply into it. A misformed SQL query embedded into a
   PL/SQL program will get a compile-time error, because it will be a
   syntax error in the PL/SQL program, too. It's also fairly easy to mix
   host language expressions with SQL queries, and it has a number of
   syntactic constructs (select into, cursor for-loops) that make it less
   needful to explicitly manage cursors.

   You can *use* macros to build a sublanguage that gets you most of this
   power in a general-purpose language. You can write your macro
   definitions so that an improperly formed query will cause a host
   language syntax error, and you can trivially add the iteration and
   other constructs that make cursor management easier. The one big miss
   with a macro sublanguage is that PL/SQL will check to make sure that
   all of the columns and tables are all consistent before running, and
   we can't do that, only because the compiler can't query the database.

   I suppose a procedural macro system theoretically *could* do that(!),
   but Needle's macros are based vaguely on an extensible grammar model.

Thanks Neel. I agree that the integration of SQL w/ the language
datatype *is* the big win (and loss) w/ PL/SQL. I thought you were
going to point out some creative way of using DBMS_SQL :). Personally
I've never cared too much for the syntax checking ability of PL/SQL
(wrt. column datatypes etc.) -- I know it's there, but given %type and
other such facilities, I rarely stumble across that type of error any

Personally speaking, if any of the LL languages could demonstrate such
deep integration w/ SQL (esp. wrt dynamic tables etc.) that could be
something genuinely new and worth looking into.