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

Re: Macros Make Me Mad [Re: Database languages]



Dave Long writes:
> 
> > 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)

If you just have one set of macros, then it's just the same thing as a
source-to-source translator. However, once you *two* such translators,
you have the problem that the extensions that each translator defines
are unparseable by the second. If your parser knows about your macro
system, then you can combine them both in the same program without
difficulty. It's that integration that's the main win.

> > 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 addition to grabbing data from the database, I also needed to put
the results back into it, and potentially to draw them out again in
other routines, so I needed two way communication. I also wanted to be
able to "check in" changes as the program proceeded, so that if there
was a crash we wouldn't have to restart the whole computation. My
ideal language would have permitted me to mix both database and
mathematical operations freely -- I would have really liked having
something like the Erlangers' mnesia or Noel Walsh's SchemeQL.

(I should note that it's not SQL itself that I wanted; I wanted easy
access to the Oracle database, and the syntax was not that important.)

-- 
Neel Krishnaswami
neelk@alum.mit.edu