employer
/
tame
1
0
Fork 0
Code Packages Releases Activity
tame/tamer/tests/xmli/template/expected.xml

157 lines
2.9 KiB
XML
Raw Normal View History

tamer: tests/xmli: Break apart single test case This would have gotten unwieldy as time goes on, and already made looking at traces very difficult. DEV-13708
2023-03-09 09:19:05 -05:00
tamer: asg::graph::object::xir: Initial rate element reconstruction This extends the POC a bit by beginning to reconstruct rate blocks (note that NIR isn't producing sub-expressions yet). Importantly, this also adds the first system tests, now that we have an end-to-end system. This not only gives me confidence that the system is producing the expected output, but serves as a compromise: writing unit or integration tests for this program derivation would be a great deal of work, and wouldn't even catch the bugs I'm worried most about; the lowering operation can be written in such a way as to give me high confidence in its correctness without those more granular tests, or in conjunction with unit or integration tests for a smaller portion. DEV-13708
2023-02-22 23:03:42 -05:00
<package xmlns="http://www.lovullo.com/rater"
xmlns:c="http://www.lovullo.com/calc"
xmlns:t="http://www.lovullo.com/rater/apply-template">
tamer: NIR->xmli template definition setup This sets the stage for template parsing, and finally decides how we're going to represent templates on the ASG. This is going to start simple, since my original plans for improving how templates are handled (conceptually) is going to have to wait. This is the last difficult object type to figure out, with respect to graph representation and derivation, so I wanted to get it out of the way. DEV-13708
2023-02-28 15:31:49 -05:00
<template name="_empty_" />
tamer: asg::air: Extract template parsing into own parser Just as was done with the expression parser, which this will utilize. This initializes it, but doesn't yet make use of it (`AirExprAggregate`). Refactoring was definitely needed; decomposing this is quite a bit of work, in no small part because of the complexity. This helps significantly. DEV-13708
2023-03-07 12:41:47 -05:00
tamer: asg::air::tpl: Parse template body expressions And finally we have tokens aggregated onto the ASG in the context of a template. I expected to arrive here much more quickly, but there was a lot of necessary refactoring. There's a lot more that could be done, but I need to continue; I had wanted this done a week ago. It is worth noting, though, that this finally achieves something I had been wondering about since the inception of this project---how I'd represent templates on the graph. I think this worked out rather nicely. It wasn't even until a few months ago that I decided to use AIR instead of NIR for that purpose (NIR wouldn't have worked). And note how I didn't have to touch the program derivation at all---the system test just works with the AIR change, because of the consistent construction of the graph. Beautiful. DEV-13708
2023-03-08 14:47:31 -05:00
<template name="_with-static-reachable_">
tamer: tests/xmli/expected.xml: Align with src This just makes this easier to compare side-by-side. DEV-13708
2023-03-08 23:49:03 -05:00
tamer: asg::air::tpl: Parse template body expressions And finally we have tokens aggregated onto the ASG in the context of a template. I expected to arrive here much more quickly, but there was a lot of necessary refactoring. There's a lot more that could be done, but I need to continue; I had wanted this done a week ago. It is worth noting, though, that this finally achieves something I had been wondering about since the inception of this project---how I'd represent templates on the graph. I think this worked out rather nicely. It wasn't even until a few months ago that I decided to use AIR instead of NIR for that purpose (NIR wouldn't have worked). And note how I didn't have to touch the program derivation at all---the system test just works with the AIR change, because of the consistent construction of the graph. Beautiful. DEV-13708
2023-03-08 14:47:31 -05:00
<rate yields="tplStaticA">
<c:sum />
</rate>
<classify as="tpl-static-b">
<any />
</classify>
</template>
tamer: asg::air: Template support for dangling expressions The intent was to have a very simple implementation of `hold_dangling` and have everything work. But, I had a nasty surprise when the system tests caught bug caused by some interesting depth interactions as it relates to `xmli` and auto-closing. I added an extra test/example in `asg::graph::visit::test` to illustrate the situation; it was difficult to derive from the traces, but trivially obvious once I wrote it out as an example. With that, templates can now aggregate tokens for dangling expressions. DEV-13708
2023-03-08 23:44:40 -05:00
<template name="_with-static-unreachable_">
tamer: tests/xmli/expected.xml: Align with src This just makes this easier to compare side-by-side. DEV-13708
2023-03-08 23:49:03 -05:00
tamer: asg::air: Template support for dangling expressions The intent was to have a very simple implementation of `hold_dangling` and have everything work. But, I had a nasty surprise when the system tests caught bug caused by some interesting depth interactions as it relates to `xmli` and auto-closing. I added an extra test/example in `asg::graph::visit::test` to illustrate the situation; it was difficult to derive from the traces, but trivially obvious once I wrote it out as an example. With that, templates can now aggregate tokens for dangling expressions. DEV-13708
2023-03-08 23:44:40 -05:00
<c:sum>
<c:product />
</c:sum>
<c:product>
<c:sum />
</c:product>
</template>
<template name="_with-static-mix-reachability_">
tamer: tests/xmli/expected.xml: Align with src This just makes this easier to compare side-by-side. DEV-13708
2023-03-08 23:49:03 -05:00
tamer: asg::air: Template support for dangling expressions The intent was to have a very simple implementation of `hold_dangling` and have everything work. But, I had a nasty surprise when the system tests caught bug caused by some interesting depth interactions as it relates to `xmli` and auto-closing. I added an extra test/example in `asg::graph::visit::test` to illustrate the situation; it was difficult to derive from the traces, but trivially obvious once I wrote it out as an example. With that, templates can now aggregate tokens for dangling expressions. DEV-13708
2023-03-08 23:44:40 -05:00
<c:sum>
<c:product />
</c:sum>
<c:product>
<c:sum />
</c:product>
tamer: tests/xmli/expected.xml: Align with src This just makes this easier to compare side-by-side. DEV-13708
2023-03-08 23:49:03 -05:00
tamer: Very basic support for template application NIR -> xmli This this a big change that's difficult to break up, and I don't have the energy after it. This introduces nullary template application, short- and long-form. Note that a body of the short form is a `@values@` argument, so that's not supported yet. This continues to formalize the idea of what "template application" and "template expansion" mean in TAMER. It makes a separate `TplApply` unnecessary, because now application is simply a reference to a template. Expansion and application are one and the same: when a template expands, it'll re-bind metavariables to the parent context. So in a template context, this amounts to application. But applying a closed template will have nothing to bind, and so is equivalent to expansion. And since `Meta` objects are not valid outside of a `Tpl` context, applying a non-closed template outside of another template will be invalid. So we get all of this with a single primitive (getting the "value" of a template). The expansion is conceptually like `,@` in Lisp, where we're splicing trees. It's a mess in some spots, but I want to get this committed before I do a little bit of cleanup.
2023-03-17 10:25:56 -04:00
tamer: asg::air: Template support for dangling expressions The intent was to have a very simple implementation of `hold_dangling` and have everything work. But, I had a nasty surprise when the system tests caught bug caused by some interesting depth interactions as it relates to `xmli` and auto-closing. I added an extra test/example in `asg::graph::visit::test` to illustrate the situation; it was difficult to derive from the traces, but trivially obvious once I wrote it out as an example. With that, templates can now aggregate tokens for dangling expressions. DEV-13708
2023-03-08 23:44:40 -05:00
<rate yields="tplStaticMix" />
<c:sum>
<c:product />
</c:sum>
</template>
tamer: Very basic support for template application NIR -> xmli This this a big change that's difficult to break up, and I don't have the energy after it. This introduces nullary template application, short- and long-form. Note that a body of the short form is a `@values@` argument, so that's not supported yet. This continues to formalize the idea of what "template application" and "template expansion" mean in TAMER. It makes a separate `TplApply` unnecessary, because now application is simply a reference to a template. Expansion and application are one and the same: when a template expands, it'll re-bind metavariables to the parent context. So in a template context, this amounts to application. But applying a closed template will have nothing to bind, and so is equivalent to expansion. And since `Meta` objects are not valid outside of a `Tpl` context, applying a non-closed template outside of another template will be invalid. So we get all of this with a single primitive (getting the "value" of a template). The expansion is conceptually like `,@` in Lisp, where we're splicing trees. It's a mess in some spots, but I want to get this committed before I do a little bit of cleanup.
2023-03-17 10:25:56 -04:00
tamer: asg: Shorthand and long-form template arguments This applies to template application only; there's still some work to do for template parameters in definitions (well, for deriving them in `xmli` at least). And, as you can see, there's still a lot of TODO items here. I ended up backtracking on tree edges to Meta, and even on cross edges to Meta, because it complicated xmli derivation with no benefit right now; maybe a cross edge will be re-added in the future, but I need to move on and see where this takes me. But, it works. DEV-13708
2023-03-23 00:04:53 -04:00
<template name="_short-hand-nullary_" />
tamer: Very basic support for template application NIR -> xmli This this a big change that's difficult to break up, and I don't have the energy after it. This introduces nullary template application, short- and long-form. Note that a body of the short form is a `@values@` argument, so that's not supported yet. This continues to formalize the idea of what "template application" and "template expansion" mean in TAMER. It makes a separate `TplApply` unnecessary, because now application is simply a reference to a template. Expansion and application are one and the same: when a template expands, it'll re-bind metavariables to the parent context. So in a template context, this amounts to application. But applying a closed template will have nothing to bind, and so is equivalent to expansion. And since `Meta` objects are not valid outside of a `Tpl` context, applying a non-closed template outside of another template will be invalid. So we get all of this with a single primitive (getting the "value" of a template). The expansion is conceptually like `,@` in Lisp, where we're splicing trees. It's a mess in some spots, but I want to get this committed before I do a little bit of cleanup.
2023-03-17 10:25:56 -04:00
<apply-template name="_short-hand-nullary_" />
tamer: asg: Shorthand and long-form template arguments This applies to template application only; there's still some work to do for template parameters in definitions (well, for deriving them in `xmli` at least). And, as you can see, there's still a lot of TODO items here. I ended up backtracking on tree edges to Meta, and even on cross edges to Meta, because it complicated xmli derivation with no benefit right now; maybe a cross edge will be re-added in the future, but I need to move on and see where this takes me. But, it works. DEV-13708
2023-03-23 00:04:53 -04:00
<template name="_short-hand-unary_" />
<apply-template name="_short-hand-unary_">
<with-param name="@foo@" value="bar" />
</apply-template>
<template name="_short-hand-nary_" />
<apply-template name="_short-hand-nary_">
<with-param name="@foo@" value="bar" />
<with-param name="@bar@" value="baz" />
<with-param name="@baz@" value="quux" />
</apply-template>
tamer: nir::tplshort: Desugar body into @values@ 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
2023-03-23 14:40:40 -04:00
<template name="_short-hand-nullary-body_" />
<apply-template name="_short-hand-nullary-body_">
<with-param name="@values@" value="___dsgr-c23___" />
</apply-template>
<template name="___dsgr-c23___">
<c:product>
<c:sum />
</c:product>
</template>
<template name="_short-hand-nary-body_" />
<apply-template name="_short-hand-nary-body_">
<with-param name="@bar@" value="baz" />
<with-param name="@baz@" value="quux" />
<with-param name="@values@" value="___dsgr-cc2___" />
</apply-template>
<template name="___dsgr-cc2___">
<c:sum>
<c:product />
</c:sum>
</template>
tamer: asg: Initial nested template supported I had hoped this would be considerably easier to implement, but there are some confounding factors. First of all: this accomplishes the initial task of getting nested template applications and definitions re-output in the `xmli` file. But to do so successfully, some assumptions had to be made. The primary issue is that of scope. The old (XSLT-based) TAME relied on the output JS to handle lexical scope for it at runtime in most situations. In the case of the template system, when scoping/shadowing were needed, complex and buggy XPaths were used to make a best effort. The equivalent here would be a graph traversal, which is not ideal. I had begun going down the rabbit hole of formalizing lexical scope for TAMER with environments, but I want to get this committed and working first; I've been holding onto this and breaking off changes for some time now. DEV-13708
2023-04-05 10:45:54 -04:00
<template name="_short-hand-nullary-outer_" />
<apply-template name="_short-hand-nullary-outer_">
<with-param name="@values@" value="___dsgr-d72___" />
</apply-template>
<template name="___dsgr-d72___">
<template name="_short-hand-nullary-inner-dfn-inner_" />
<apply-template name="_short-hand-nullary-inner-dfn-inner_" />
</template>
<template name="_short-hand-nullary-inner-dfn-outer_" />
<apply-template name="_short-hand-nullary-outer_">
<with-param name="@values@" value="___dsgr-e59___" />
</apply-template>
<template name="___dsgr-e59___">
<apply-template name="_short-hand-nullary-inner-dfn-outer_" />
</template>
<template name="_short-hand-unary-with-values_" />
<apply-template name="_short-hand-unary-with-values_">
<with-param name="@foo@" value="bar" />
<with-param name="@values@" value="___dsgr-eff___" />
</apply-template>
<template name="___dsgr-eff___">
<template name="_short-hand-unary-with-values-inner_" />
<apply-template name="_short-hand-unary-with-values-inner_" />
</template>
tamer: NIR->xmli: Initial classify, any, all support Just as `rate` is a `sum`, `classify` is an `all` by default. The `@any` attribute will change that interpretation, though I only intend to recognize that in parsing later on, not emit that in XMLI. DEV-13708
2023-02-24 23:01:02 -05:00
</package>
tamer: tests/xmli: Break apart single test case This would have gotten unwieldy as time goes on, and already made looking at traces very difficult. DEV-13708
2023-03-09 09:19:05 -05:00