On 3/24/17, James K. Lowden <jklow...@schemamania.org> wrote: > > I probably shouldn't have referred specifically to the AST. The output > I think SQLite users could benefit from isn't the emitted bytecode. > It's the parse tree: the affected objects and the operations on them. > > I don't see how the parse tree would be volatile or hard to > understand.
The "Parse tree" is what I meant by AST. The parse tree used by SQLite is not the nice clean easy-to-follow parse tree that you saw coming out of YACC in your compiler-construction class. In SQLite, is hacked and highly optimized to minimize the number of memory allocations and number of CPU cycles. It is not a pretty sight. And it changes frequently as we work on new feature and optimizations. To put it another way, the parse tree does not reflect the syntax of the input exactly. Many transformations occur before generating the parse tree, since it is faster and cheaper to generate a semi-optimized parse tree than it is to generate a parse tree that directly mirrors the input syntax, then transform it via a separate optimizer pass. You can actually get an ASCII-art representation of the parse tree out of the CLI if you compile with -DSQLITE_DEBUG and -DSQLITE_ENABLE_SELECTTRACE and -DSQLITE_ENABLE_WHERETRACE. In the shell, run the command ".selecttrace 0xffff" then enter a query of some kind, and you will get to see the parse tree as in moves through its various error checking, optimization, and code generation phases. It is this parse tree that you want to see, right? And that is the same parse tree that is frequently modified in order to accomplish new features and optimizations, and which we are therefore unwilling to make available in a standard interface. -- D. Richard Hipp d...@sqlite.org _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
