[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: OOQuery Language
Hi Don,
Thanks for the answer. I just comment here a little about the grammar, and
talk more about the interpreter in the next post.
> I'm open to working together in whatever manner that would be mutually
> beneficial on a modular OQL interpreter that would support pluggable
> 'drivers' and would like to explore how we might do this. I'm at the very
> beginning of this project and would like to hear your thoughts on the
> interpreter structure and the APIs.
>
> At this time I probably would not attempt to build a generic ozone 'driver'
> on my own but rather implement what was needed on my project. Hopefully
> that could provide a start on a generic 'driver'.
More on that in the next post.
> I've been working with JavaCC and was wondering why you chose SableCC?
>
> My preference is to use JavaCC due to its wide acceptance, support and the
> wide variety of available grammars (e.g.
> http://www.cobase.cs.ucla.edu/pub/javacc/ ). Also I'm using it in some other
> parsing tasks at this time.
>
> The JavaCC OQL grammar I found most promising so far is OQLMulti.jj
> available at http://davis.wpi.edu/dsrg/OOSE/OQL/ . I have no experience
> using this grammar and don't know how it compares to your OQL3.grammar .
>
> Your thoughts?
We have been using JavaCC for a while, then it separated from Sun into
Metamata, and the free support was under question mark, it was not LGPLed
(is it now?) and we have been looking for a new parser generator. SableCC
was the only fully object-oriented one, with Java 1 (special collections
module) and Java 2 (Java 2 Collections framework) support, LGPLed, with
clear separation of the different phases of the parser development,
etc. It is really nice and easy to use, and it has very pure object
oriented structure:
all tokens are represented by classes and all productions are represented
by classes - so one can do easily tree traversal by visitor pattern
(unlike other frameworks where some tokens are distinguished from others
by int-based identifiers, and visitor patterns has to be mixed with huge
switch-case statements), it forces you to a particular design decisions,
which makes team development easier - the basic AST generation is seperate
from AST manipulations, and this is seperate from
interpretation/compilation traversal (unlike JavaCC where you are free to
mix all of it into single grammar file). However, it depends what you
like - if you are reallu into OO, once you start using SableCC there is no
way back. But if you are more into functional programming, or C-like
programming, you will complain that SableCC forces you to particular
design decisions.
SableCC can take pure EBNF grammars (with very small amount of syntactical
sugar), so it gives you big advantage at the beggining of the development.
OQL3.grammar is a mixture of EBNF of OQL3 plus some of tokens and
productions which are used once the generated AST is simiplified for
easier traversal.
As for drawbacks, SableCC is really slow, and memory consuming (all is
represented as classes, so you end up with 100s of classes which needs to
be loaded into JVM). Also object oriented switch (visitor pattern) is much
slower than switch-case based switching.
But of course... parsing is not a key point here, isn't it? ;o)
I think that "modular interpreter", "query kernel", etc. could be used
from any tree traversal module. I will write more on the real topic in my
next post.
cheers
Mariusz