[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)

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?)


* "the uses of macros (Re: various recent ll1 threads)"


> 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")