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

48 lines
836 B
XML
Raw Normal View History

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">
<rate yields="rateFoo" />
tamer: Lower sum expressions This was a fairly simple addition, since rate blocks already lower into sum expressions; these are just non-identified. This does emphasize that the nir::parse `ele_parse!` abstraction I spent so much time on ended up not being a perfect fit, as it now has some boilerplate after it was stripped of much of its capabilities some time ago. Don't worry, `nir::air` and `asg::graph::xmli` will get cleaned up. DEV-13708
2023-02-22 23:45:23 -05:00
<rate yields="rateBar">
<c:sum />
tamer: NIR->xmli: Initial product expression The element only, no attributes yet. I'll keep forming boilerplate until abstraction points become obvious with more variety; this is still pretty close to what was already supported. DEV-13708
2023-02-24 15:55:25 -05:00
<c:product />
tamer: Lower sum expressions This was a fairly simple addition, since rate blocks already lower into sum expressions; these are just non-identified. This does emphasize that the nir::parse `ele_parse!` abstraction I spent so much time on ended up not being a perfect fit, as it now has some boilerplate after it was stripped of much of its capabilities some time ago. Don't worry, `nir::air` and `asg::graph::xmli` will get cleaned up. DEV-13708
2023-02-22 23:45:23 -05:00
</rate>
<rate yields="rateBaz">
<c:sum>
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
<c:product />
tamer: Lower sum expressions This was a fairly simple addition, since rate blocks already lower into sum expressions; these are just non-identified. This does emphasize that the nir::parse `ele_parse!` abstraction I spent so much time on ended up not being a perfect fit, as it now has some boilerplate after it was stripped of much of its capabilities some time ago. Don't worry, `nir::air` and `asg::graph::xmli` will get cleaned up. DEV-13708
2023-02-22 23:45:23 -05:00
<c:sum />
</c:sum>
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
<c:product>
tamer: Lower sum expressions This was a fairly simple addition, since rate blocks already lower into sum expressions; these are just non-identified. This does emphasize that the nir::parse `ele_parse!` abstraction I spent so much time on ended up not being a perfect fit, as it now has some boilerplate after it was stripped of much of its capabilities some time ago. Don't worry, `nir::air` and `asg::graph::xmli` will get cleaned up. DEV-13708
2023-02-22 23:45:23 -05:00
<c:sum />
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
<c:product />
tamer: Lower sum expressions This was a fairly simple addition, since rate blocks already lower into sum expressions; these are just non-identified. This does emphasize that the nir::parse `ele_parse!` abstraction I spent so much time on ended up not being a perfect fit, as it now has some boilerplate after it was stripped of much of its capabilities some time ago. Don't worry, `nir::air` and `asg::graph::xmli` will get cleaned up. DEV-13708
2023-02-22 23:45:23 -05:00
<c:sum />
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
</c:product>
tamer: Lower sum expressions This was a fairly simple addition, since rate blocks already lower into sum expressions; these are just non-identified. This does emphasize that the nir::parse `ele_parse!` abstraction I spent so much time on ended up not being a perfect fit, as it now has some boilerplate after it was stripped of much of its capabilities some time ago. Don't worry, `nir::air` and `asg::graph::xmli` will get cleaned up. DEV-13708
2023-02-22 23:45:23 -05:00
</rate>
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
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
<classify as="always" />
<classify as="sometimes">
<any>
<all />
<any />
<all />
</any>
<any />
</classify>
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
<rate yields="postTpl" />
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_">
<rate yields="tplStaticA">
<c:sum />
</rate>
<classify as="tpl-static-b">
<any />
</classify>
</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>