@@ -4,6 +4,11 @@ The grammar is located in `SQLPGrammar.y`, and non-keyword types (such as `INTEG
For parsing any general string into a tree of `cons_cells`, run `make` then run `./Parser`. An example of a test input is `PROJ (AS (SPCOL (VAR (s) PF (ATTR (name)))) ATOM (TABLE (student) VAR (s)))`. Every clause encosed in brackets is nested within a child `cons_cell`, and any two adjacent terms are connected via the `next` pointer.
NOTE OF THINGS TO BE CHANGED/CAREFUL ABOUT:
In `SQLPGrammar.y` currently we reuse `create_rename_operator` in `select_list` section, however this needs to be changed in the future as this is incorrect. Instead this should be used when we rename what is selected, for example `select s.t as st ...` should become something like `PROJ (RENAME (s.t (st)) ...`. Currently we don't support this type of query with `as` in it even though it's valid.
Also the Makefile only has 2 commands, `make` and `make clean`. `make` will create both the SQLPParser and Parser programs to do what was described above. Maybe this should be changed in the future to be separate but we'll leave that discussion for the future.
A common way of defining the behavior of a process or thread in cases where
performance is critical is in terms of a collection of n+1 files containing
code in the C programming language: n "module" files with a ".c" suffix that
...
...
@@ -20,4 +25,4 @@ procedures is re-coded by using a variant of the static embedded SQL protocol.
Note that each of the tools comprising the LDI system define the behavior of
such a process or thread, and are therefore also coded in this manner. Thus, the
tools themselves are benchmarks for their own evaluation.
\ No newline at end of file
tools themselves are benchmarks for their own evaluation.