Mike Gerwitz
975f60bff9
This represents a significant departure from how the XSLT-based TAME handles the `@values@` param, but it will end up having the same effect. It builds upon prior work, utilizing the fact that referencing a template in TAMER will expand it. The problem is this: allowing trees in `Meta` would add yet another container; we have `Pkg` and `Tpl` already. This was the same problem with template application---I didn't want to add support for binding arguments separately, and so re-used templates themselves, reaching the generalization I just mentioned above. `Meta` is intended to be a lexical metasyntatic variable. That keeps its implementation quite simple. But if we start allowing trees, that gets rather complicated really quickly, and starts to require much more complex AIR parser state. But we can accomplish the same behavior by desugaring into an existing container---a template---and placing the body within it. Then, in the future, we'll parse `param-copy` into a simple `Air::RefIdent`, which will expand the closed template and produce the same result as it does today in the XSLT-based system. This leaves open issues of closure (variable binding) in complex scenarios, such as in templates that introduce metavariables to be utilized by the body. That's never a practice I liked, but we'll see how things evolve. Further, this does not yet handle nested template applications. But this saved me a ton of work. Desugaring is much simpler. The question is going to be how the XSLT-based compiler responds to this for large packages with thousands of template applications. I'll have to see if it's worth the hit at that time, or if we should inline it when generating the `xmli` file, producing the same `@values@` as before. But as it stands at this moment, the output is _not_ compatible with the current compiler, as it expects `@values@` to be a tree, so a modification would have to be made there. DEV-13708 |
||
|---|---|---|
| .. | ||
| classify | ||
| combined | ||
| empty | ||
| rate | ||
| template | ||
| .gitignore | ||
| README.md | ||
| test-xmli | ||
README.md
XMLI System Test
The xmli file is an intermediate file that serves as a handoff between
TAMER and the XSLT-based compiler:
xml -> (TAMER) -> xmli -> (TAME XSLT) -> xmlo
TAMER gets the first shot at processing, and then the compilation process continues with the XSLT-based compiler. This allows TAMER to incrementally augment and manipulate the source file and remove responsibilities from TAME XSLT.
Tests in this directory ensure that this process is working as intended. TAMER's failure to perform a proper handoff will cause TAME XSLT to compile sources incorrectly, since TAMER will have rewritten them to something else.
This handoff is more than just echoing tokens back into a file---it derives a new program from the state of the ASG. This program may have a slightly different representation than the original sources, but it must express an equivalent program, and the program must be at least as performant when emitted by TAME XSLT.
Running Tests
Test are prefixed with test-* and are executable. They must be invoked
with the environment variable PATH_TAMEC set to the path of tamec
relative to the working directory.
Test cases are organized into sub-directories with src.xml and
expected.xml files. src.xml will be compiled with tamec, its output
formatted with xmllint --format, and diff'd against the
xmllint-formatted output of expected.xml.