Kay Röpke wrote:
hi!
On Mar 4, 2009, at 3:42 AM, Baron Schwartz wrote:
I'm just curious....
You seem to imply that parsing involves building the parse tree.
Logically, parsing and building the parse tree could be separated
(event based parser, where the parser signals parse events and a
listener does something interesting such as building the parse tree)
I'm just curious if there is some rule ofthe tumb that determines
whether it'd be better to integrate building the parse tree rather
than abstract it using an event-based parser design.
I think Jim kind of said this already, but I'll say it a different
way. You're probably confusing parsing with tokenizing and lexing and
all kinds of other stuff.
my 2¢:
1) retain the current lexer if you care for charset support (drizzle can
probably skip this)
2) retain the current lexer if you care for all the edge cases it
handles (hard to fully recreate with a tool, trust me)
3) build a grammar for the MySQL/drizzle language, start small, without
joins and subselects feeding of the token stream from the existing lexer
(this is one function and one token struct, should be relatively easy to
adapt to other lexers)
4) let the generated (or handwritten if you have too much time) parser
build an AST(!) _not_ a parse tree (reason: parse trees change as you
change the parser, ASTs are not supposed to change simply because you
split a recognition step. an AST needs design, obviously)
5) _only_ build an AST, do no binding or anything else (except you need
it to successfully parse, like names of functions added by plugins or
something like that - note: you probably do not need the function's
prototypes, treat that part as a name binding problem)
6) traverse the AST, do name binding (if there are more things you need
to do to verify the semantics of the sentence, either do multiple passes
or if you know beforehand that this will be too slow, try to do it in
one pass)
7) optimize the tree (probably a peephole optimizer, like constant
folding etc)
8) restructure the rest of the code that it can deal with the tree
you've built (this should probably not be the last step chronologically,
because i'm sure there will be problems where you cannot easily change
code to the nice new reality you've created with the AST ;))
+1
Designing a query execution plan from the parse tree, now thats a
different matter... might be best not to refer to the MySQL codebase
for any inspiration on this ;-)
heh :P JavaDB is...
...but whereas MySQL is optimized for immediate execution, JavaDB is
optimized for prepared statements ;)
Thanks,
Roy
_______________________________________________
Mailing list: https://launchpad.net/~drizzle-discuss
Post to : [email protected]
Unsubscribe : https://launchpad.net/~drizzle-discuss
More help : https://help.launchpad.net/ListHelp
