Re: Macros Make Me Mad

[address@hidden (Michael Sperber [Mr. Preprocessor])]

>>>>> "Sundar" == Sundar Narasimhan <sundar@ascent.com> writes:

Sundar> Thanks Neel. I agree that the integration of SQL w/ the language
Sundar> datatype *is* the big win (and loss) w/ PL/SQL. 

Sundar>    Unfortunately, the integration in this specific case is surprisingly
Sundar>    bad, because you can't abstract over many entities of the sublanguage,
Sundar>    i.e. tables or the names of fields, which in practice leads to the
Sundar>    worst rashes of code duplication I've ever seen (at least when used in
Sundar>    industry).  You can essentially only stick verbatim SQL code in your
Sundar>    PL/SQL program.

Sundar> Agreed. But the procedural API's (such as JDBC/ODBC, SQLJ etc. are not
Sundar> much better). Java is particularly bad in this respect, and results in
Sundar> equal (or worse) amountts of code duplication because you can't easily
Sundar> write before/after methods. Some say this is due to lack of true
Sundar> closures, some say it's because of "try/catch" semantics .. which do
Sundar> not interact well w/ procedural API's for controlling transaction
Sundar> boundaries.. whatever.

I agree absolutely.  But then again, these languages weren't designed
for embedding SQL.

Sundar> What *is* the solution you would prefer or advocate? Just curious,

A combinator language for SQL.  Francisco Solsona's SchemeQL goes in
that direction, as probably do its Common Lisp counterparts.  Of
course, these don't give you static syntax checking, but I'm pretty
sure you'd be able to model this in some variant of Hindley/Milner.
In fact, I'd be surprised if the ML/Haskell folks haven't come up with
something in that direction; it's just something I haven't researched.

-- 
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla