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 )
<<standard disclaimer>> <<gratuitous witticism>> <<your ad here>>