[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Macros Make Me Mad [Re: Database languages]
> 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.
So far, it sounds like the largest
difference between macros and source
translation is in whether the output
is typically rescanned. (yes for a
macro expander, no for a translator)
Otherwise:
macros src xlat
------ --------
+ + static errors caught at compile time
+ + allows compiler to optimize, or at least ameliorate
- - painful to debug, unless simple
- - GIGO
and, as mentioned earlier*,
+ + data sublanguages (incl. Weinreb's defcommand)
? ? binding constructs
+ + evaluation reordering
(and the largest difference between
macros and classes and functions is
that the latter are well supported
by common debuggers?)
-Dave
* "the uses of macros (Re: various recent ll1 threads)"
<http://www.ai.mit.edu/~gregs/ll1-discuss-archive-html/msg01539.html>
::::::
> It seems like most of the internal applications people write these
> days involve database access. My own job was data-mining hooked up
> to a SQL database. I'd have loved to use a matrix language that knew
> SQL.
Would you have needed a matrix language
that knew SQL, or would it have sufficed
to be able to couple a SQL data producer
with a matrix language data consumer?
In 1960's parlance: one (co)routine copies
records from a table; the other takes the
resulting ravelling, and rhos and reduces.
In 1990's parlance: one thread unfolds
(coalgebraically) a SQL query; the other
takes the resulting stream and folds
(algebraically) the computation with it.
(Place a bounded buffer between the two,
such as a unix pipe, and one can avoid
consing. In the 60's, we might've said
"running in constant space"; in the 90's
we might've said "deforested")