Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ncar!ames!pacbell!rtech!billc@rtech.UUCP
From: billc@rtech.UUCP (Bill Coffin)
Newsgroups: comp.databases
Subject: Re: Parsing Query Languages in the Client or Server
Message-ID: <3699@rtech.rtech.com>
Date: 26 Sep 89 00:14:13 GMT
References: <17466@pasteur.Berkeley.EDU>
Sender: news@rtech.rtech.com
Lines: 40
From article <17466@pasteur.Berkeley.EDU>, by mao@eden (Mike Olson):
>> From: forrest@sybase.com (Jon Forrest)
>
Hi Jon, Hi Mike. For those of you that just joined us, I also worked at
Britton-Lee (er, ah, "Sharebase"). I now work at RTI.
Jon, I don't think you can avoid a front-end parse if you support
host-language embeddings. You still have to poke around for host-language
variables and other information at compile time.
Personally, I think RTI (oh yes, and Sybase too) have the right idea in
sending text:
* Interoperability is simpler, and will get simpler yet as vendors
continue to converge on a standard SQL.
* If you have a parse-tree interface, you don't know who might have
written the parser -- you might get some strange stuff. There were lot's
of eccentric parser that talked to BLI machines, and BLI was not very
robust in the face of parse-tree berserkness.
* When BLI started up they expected VARs to write these parsers. VARs
decided this was too hard, and thunderously ignored BLI. BLI had to
write a parser and port it everywhere. If you want VARs and others to
get involved, it behooves you to support a non-befuddling interface.
* Mike argues that taking away the parse-tree interface makes it impossible
to implement new languages. I don't believe this -- BLI's parse-trees
are semantically QUEL (IDL) oriented, so it was just about impossible to
do a different language. I implemented Britton-Lee's first version of
SQL, translating SQL into these parse trees. It was a dreadful hack that
couldn't adequately model SQL. (And when BLI went into nosedive mode,
yours-truly's head was amongst those that rolled.) I don't think it's
possible to do an interface that is independent of the query-language
and also non-procedural.
billc@rtech.uucp ( or, if you must, {sun,pyramid,mtxinu,amdahl}!rtech!billc )
<> <> <>