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

74 lines
2.0 KiB
XML
Raw Normal View History

tamer: xmli reconstruction of desugared interpolated metavars Well, this is both good news and bad news. The good news is that this finally produces the expected output and reconstructs sources from interpolated values on the ASG. Yay! ...the bad news is that it's wrong. Notice how the fixpoint test is disabled. So, my plan was originally to commit it like this first and see if I was comfortable relaxing the convention that `<param>` nodes had to appear in the header. That's nice to do, that's cleaner to do, but would the XSLT-based compiler really care? I had to investigate. Well, turns out that TAMER does care. Because, well over a decade ago, I re-used `<param>`, which could represent not only a template param, but also a global param, or a function param. So, XML->NIR considers all `<param>` nodes at the head of a template to be template parameters. But after the first non-header element, we transition to another state that allows it to be pretty much anything. And so, I can't relax that restriction. And because of that, I can't just stream the tree to the xmli generator, I'll have to queue up nodes and order them. Oh well, I tried. DEV-13163
2023-07-13 16:41:27 -04:00
<package xmlns="http://www.lovullo.com/rater"
xmlns:c="http://www.lovullo.com/calc"
xmlns:t="http://www.lovullo.com/rater/apply-template">
<template name="_interp-non-bind_"
desc="Interpolation in non-binding position">
<param name="@___dsgr_335@"
tamer: nir::interp: Do not include original specification in generated desc This is a really obvious problem in retrospect, which makes me feel rather silly. The output was useful, but I don't have time to deal with this any further right now. The comments in the commit explain the problem---that the output ends up being interpolated as part of the fixpoint test, in an incorrect context, and so the code that we generate is invalid. Also goes to show why the fixpoint tests are important. (Yes, they're still disabled for meta-interp, I'm trying to get them enabled.) DEV-13163
2023-07-18 11:17:51 -04:00
desc="Generated from interpolated string">
tamer: xmli reconstruction of desugared interpolated metavars Well, this is both good news and bad news. The good news is that this finally produces the expected output and reconstructs sources from interpolated values on the ASG. Yay! ...the bad news is that it's wrong. Notice how the fixpoint test is disabled. So, my plan was originally to commit it like this first and see if I was comfortable relaxing the convention that `<param>` nodes had to appear in the header. That's nice to do, that's cleaner to do, but would the XSLT-based compiler really care? I had to investigate. Well, turns out that TAMER does care. Because, well over a decade ago, I re-used `<param>`, which could represent not only a template param, but also a global param, or a function param. So, XML->NIR considers all `<param>` nodes at the head of a template to be template parameters. But after the first non-header element, we transition to another state that allows it to be pretty much anything. And so, I can't relax that restriction. And because of that, I can't just stream the tree to the xmli generator, I'll have to queue up nodes and order them. Oh well, I tried. DEV-13163
2023-07-13 16:41:27 -04:00
<param-value name="@bar@" />
</param>
<param name="@___dsgr_368@"
tamer: nir::interp: Do not include original specification in generated desc This is a really obvious problem in retrospect, which makes me feel rather silly. The output was useful, but I don't have time to deal with this any further right now. The comments in the commit explain the problem---that the output ends up being interpolated as part of the fixpoint test, in an incorrect context, and so the code that we generate is invalid. Also goes to show why the fixpoint tests are important. (Yes, they're still disabled for meta-interp, I'm trying to get them enabled.) DEV-13163
2023-07-18 11:17:51 -04:00
desc="Generated from interpolated string">
tamer: xmli reconstruction of desugared interpolated metavars Well, this is both good news and bad news. The good news is that this finally produces the expected output and reconstructs sources from interpolated values on the ASG. Yay! ...the bad news is that it's wrong. Notice how the fixpoint test is disabled. So, my plan was originally to commit it like this first and see if I was comfortable relaxing the convention that `<param>` nodes had to appear in the header. That's nice to do, that's cleaner to do, but would the XSLT-based compiler really care? I had to investigate. Well, turns out that TAMER does care. Because, well over a decade ago, I re-used `<param>`, which could represent not only a template param, but also a global param, or a function param. So, XML->NIR considers all `<param>` nodes at the head of a template to be template parameters. But after the first non-header element, we transition to another state that allows it to be pretty much anything. And so, I can't relax that restriction. And because of that, I can't just stream the tree to the xmli generator, I'll have to queue up nodes and order them. Oh well, I tried. DEV-13163
2023-07-13 16:41:27 -04:00
<text>Prefix </text>
<param-value name="@bar@" />
</param>
<param name="@___dsgr_3a3@"
tamer: nir::interp: Do not include original specification in generated desc This is a really obvious problem in retrospect, which makes me feel rather silly. The output was useful, but I don't have time to deal with this any further right now. The comments in the commit explain the problem---that the output ends up being interpolated as part of the fixpoint test, in an incorrect context, and so the code that we generate is invalid. Also goes to show why the fixpoint tests are important. (Yes, they're still disabled for meta-interp, I'm trying to get them enabled.) DEV-13163
2023-07-18 11:17:51 -04:00
desc="Generated from interpolated string">
tamer: xmli reconstruction of desugared interpolated metavars Well, this is both good news and bad news. The good news is that this finally produces the expected output and reconstructs sources from interpolated values on the ASG. Yay! ...the bad news is that it's wrong. Notice how the fixpoint test is disabled. So, my plan was originally to commit it like this first and see if I was comfortable relaxing the convention that `<param>` nodes had to appear in the header. That's nice to do, that's cleaner to do, but would the XSLT-based compiler really care? I had to investigate. Well, turns out that TAMER does care. Because, well over a decade ago, I re-used `<param>`, which could represent not only a template param, but also a global param, or a function param. So, XML->NIR considers all `<param>` nodes at the head of a template to be template parameters. But after the first non-header element, we transition to another state that allows it to be pretty much anything. And so, I can't relax that restriction. And because of that, I can't just stream the tree to the xmli generator, I'll have to queue up nodes and order them. Oh well, I tried. DEV-13163
2023-07-13 16:41:27 -04:00
<param-value name="@bar@" />
<text> suffix</text>
</param>
<param name="@___dsgr_3da@"
tamer: nir::interp: Do not include original specification in generated desc This is a really obvious problem in retrospect, which makes me feel rather silly. The output was useful, but I don't have time to deal with this any further right now. The comments in the commit explain the problem---that the output ends up being interpolated as part of the fixpoint test, in an incorrect context, and so the code that we generate is invalid. Also goes to show why the fixpoint tests are important. (Yes, they're still disabled for meta-interp, I'm trying to get them enabled.) DEV-13163
2023-07-18 11:17:51 -04:00
desc="Generated from interpolated string">
tamer: xmli reconstruction of desugared interpolated metavars Well, this is both good news and bad news. The good news is that this finally produces the expected output and reconstructs sources from interpolated values on the ASG. Yay! ...the bad news is that it's wrong. Notice how the fixpoint test is disabled. So, my plan was originally to commit it like this first and see if I was comfortable relaxing the convention that `<param>` nodes had to appear in the header. That's nice to do, that's cleaner to do, but would the XSLT-based compiler really care? I had to investigate. Well, turns out that TAMER does care. Because, well over a decade ago, I re-used `<param>`, which could represent not only a template param, but also a global param, or a function param. So, XML->NIR considers all `<param>` nodes at the head of a template to be template parameters. But after the first non-header element, we transition to another state that allows it to be pretty much anything. And so, I can't relax that restriction. And because of that, I can't just stream the tree to the xmli generator, I'll have to queue up nodes and order them. Oh well, I tried. DEV-13163
2023-07-13 16:41:27 -04:00
<text>Prefix </text>
<param-value name="@bar@" />
<text> suffix</text>
</param>
tamer: asg::graph::visit::ontree: Source ordering of ontological tree This introduces the ability to specify an edge ordering for the ontological tree traversal. `tree_reconstruction` will now use a `SourceCompatibleTreeEdgeOrder`, which will traverse the graph in an order that will result in a properly ordered source reconstruction. This is needed for template headers, because interpolation causes metavariables (exposed as template params) to be mixed into the body. There's a lot of information here, including some TODOs on possible improvements. I used the unstable `is_sorted` to output how many template were already sorted, based on one of our very large packages internally that uses templates extensively, and found that none of the desugared shorthand template expansions were already ordered. If I tweak that a bit, then nearly all templates will already be ordered, reducing the work that needs to be done, leaving only template definitions with interpolation to be concerned about, which is infrequent relative to everything else. DEV-13163
2023-07-17 16:12:56 -04:00
<classify as="only" desc="@___dsgr_335@"/>
<classify as="prefixed" desc="@___dsgr_368@"/>
<classify as="suffixed" desc="@___dsgr_3a3@"/>
<classify as="both" desc="@___dsgr_3da@" />
tamer: xmli reconstruction of desugared interpolated metavars Well, this is both good news and bad news. The good news is that this finally produces the expected output and reconstructs sources from interpolated values on the ASG. Yay! ...the bad news is that it's wrong. Notice how the fixpoint test is disabled. So, my plan was originally to commit it like this first and see if I was comfortable relaxing the convention that `<param>` nodes had to appear in the header. That's nice to do, that's cleaner to do, but would the XSLT-based compiler really care? I had to investigate. Well, turns out that TAMER does care. Because, well over a decade ago, I re-used `<param>`, which could represent not only a template param, but also a global param, or a function param. So, XML->NIR considers all `<param>` nodes at the head of a template to be template parameters. But after the first non-header element, we transition to another state that allows it to be pretty much anything. And so, I can't relax that restriction. And because of that, I can't just stream the tree to the xmli generator, I'll have to queue up nodes and order them. Oh well, I tried. DEV-13163
2023-07-13 16:41:27 -04:00
</template>
<template name="_with-abstract-ident_"
desc="Metavariable interpolation in binding position">
<param name="@___dsgr_4a8@"
tamer: nir::interp: Do not include original specification in generated desc This is a really obvious problem in retrospect, which makes me feel rather silly. The output was useful, but I don't have time to deal with this any further right now. The comments in the commit explain the problem---that the output ends up being interpolated as part of the fixpoint test, in an incorrect context, and so the code that we generate is invalid. Also goes to show why the fixpoint tests are important. (Yes, they're still disabled for meta-interp, I'm trying to get them enabled.) DEV-13163
2023-07-18 11:17:51 -04:00
desc="Generated from interpolated string">
tamer: xmli reconstruction of desugared interpolated metavars Well, this is both good news and bad news. The good news is that this finally produces the expected output and reconstructs sources from interpolated values on the ASG. Yay! ...the bad news is that it's wrong. Notice how the fixpoint test is disabled. So, my plan was originally to commit it like this first and see if I was comfortable relaxing the convention that `<param>` nodes had to appear in the header. That's nice to do, that's cleaner to do, but would the XSLT-based compiler really care? I had to investigate. Well, turns out that TAMER does care. Because, well over a decade ago, I re-used `<param>`, which could represent not only a template param, but also a global param, or a function param. So, XML->NIR considers all `<param>` nodes at the head of a template to be template parameters. But after the first non-header element, we transition to another state that allows it to be pretty much anything. And so, I can't relax that restriction. And because of that, I can't just stream the tree to the xmli generator, I'll have to queue up nodes and order them. Oh well, I tried. DEV-13163
2023-07-13 16:41:27 -04:00
<param-value name="@as@" />
</param>
<param name="@___dsgr_4ca@"
tamer: nir::interp: Do not include original specification in generated desc This is a really obvious problem in retrospect, which makes me feel rather silly. The output was useful, but I don't have time to deal with this any further right now. The comments in the commit explain the problem---that the output ends up being interpolated as part of the fixpoint test, in an incorrect context, and so the code that we generate is invalid. Also goes to show why the fixpoint tests are important. (Yes, they're still disabled for meta-interp, I'm trying to get them enabled.) DEV-13163
2023-07-18 11:17:51 -04:00
desc="Generated from interpolated string">
tamer: xmli reconstruction of desugared interpolated metavars Well, this is both good news and bad news. The good news is that this finally produces the expected output and reconstructs sources from interpolated values on the ASG. Yay! ...the bad news is that it's wrong. Notice how the fixpoint test is disabled. So, my plan was originally to commit it like this first and see if I was comfortable relaxing the convention that `<param>` nodes had to appear in the header. That's nice to do, that's cleaner to do, but would the XSLT-based compiler really care? I had to investigate. Well, turns out that TAMER does care. Because, well over a decade ago, I re-used `<param>`, which could represent not only a template param, but also a global param, or a function param. So, XML->NIR considers all `<param>` nodes at the head of a template to be template parameters. But after the first non-header element, we transition to another state that allows it to be pretty much anything. And so, I can't relax that restriction. And because of that, I can't just stream the tree to the xmli generator, I'll have to queue up nodes and order them. Oh well, I tried. DEV-13163
2023-07-13 16:41:27 -04:00
<text>prefix-</text>
<param-value name="@as@" />
</param>
<param name="@___dsgr_4f4@"
tamer: nir::interp: Do not include original specification in generated desc This is a really obvious problem in retrospect, which makes me feel rather silly. The output was useful, but I don't have time to deal with this any further right now. The comments in the commit explain the problem---that the output ends up being interpolated as part of the fixpoint test, in an incorrect context, and so the code that we generate is invalid. Also goes to show why the fixpoint tests are important. (Yes, they're still disabled for meta-interp, I'm trying to get them enabled.) DEV-13163
2023-07-18 11:17:51 -04:00
desc="Generated from interpolated string">
tamer: xmli reconstruction of desugared interpolated metavars Well, this is both good news and bad news. The good news is that this finally produces the expected output and reconstructs sources from interpolated values on the ASG. Yay! ...the bad news is that it's wrong. Notice how the fixpoint test is disabled. So, my plan was originally to commit it like this first and see if I was comfortable relaxing the convention that `<param>` nodes had to appear in the header. That's nice to do, that's cleaner to do, but would the XSLT-based compiler really care? I had to investigate. Well, turns out that TAMER does care. Because, well over a decade ago, I re-used `<param>`, which could represent not only a template param, but also a global param, or a function param. So, XML->NIR considers all `<param>` nodes at the head of a template to be template parameters. But after the first non-header element, we transition to another state that allows it to be pretty much anything. And so, I can't relax that restriction. And because of that, I can't just stream the tree to the xmli generator, I'll have to queue up nodes and order them. Oh well, I tried. DEV-13163
2023-07-13 16:41:27 -04:00
<param-value name="@as@" />
<text>-suffix</text>
</param>
<param name="@___dsgr_51e@"
tamer: nir::interp: Do not include original specification in generated desc This is a really obvious problem in retrospect, which makes me feel rather silly. The output was useful, but I don't have time to deal with this any further right now. The comments in the commit explain the problem---that the output ends up being interpolated as part of the fixpoint test, in an incorrect context, and so the code that we generate is invalid. Also goes to show why the fixpoint tests are important. (Yes, they're still disabled for meta-interp, I'm trying to get them enabled.) DEV-13163
2023-07-18 11:17:51 -04:00
desc="Generated from interpolated string">
tamer: xmli reconstruction of desugared interpolated metavars Well, this is both good news and bad news. The good news is that this finally produces the expected output and reconstructs sources from interpolated values on the ASG. Yay! ...the bad news is that it's wrong. Notice how the fixpoint test is disabled. So, my plan was originally to commit it like this first and see if I was comfortable relaxing the convention that `<param>` nodes had to appear in the header. That's nice to do, that's cleaner to do, but would the XSLT-based compiler really care? I had to investigate. Well, turns out that TAMER does care. Because, well over a decade ago, I re-used `<param>`, which could represent not only a template param, but also a global param, or a function param. So, XML->NIR considers all `<param>` nodes at the head of a template to be template parameters. But after the first non-header element, we transition to another state that allows it to be pretty much anything. And so, I can't relax that restriction. And because of that, I can't just stream the tree to the xmli generator, I'll have to queue up nodes and order them. Oh well, I tried. DEV-13163
2023-07-13 16:41:27 -04:00
<text>prefix-</text>
<param-value name="@as@" />
<text>-suffix</text>
</param>
tamer: asg::graph::visit::ontree: Source ordering of ontological tree This introduces the ability to specify an edge ordering for the ontological tree traversal. `tree_reconstruction` will now use a `SourceCompatibleTreeEdgeOrder`, which will traverse the graph in an order that will result in a properly ordered source reconstruction. This is needed for template headers, because interpolation causes metavariables (exposed as template params) to be mixed into the body. There's a lot of information here, including some TODOs on possible improvements. I used the unstable `is_sorted` to output how many template were already sorted, based on one of our very large packages internally that uses templates extensively, and found that none of the desugared shorthand template expansions were already ordered. If I tweak that a bit, then nearly all templates will already be ordered, reducing the work that needs to be done, leaving only template definitions with interpolation to be concerned about, which is infrequent relative to everything else. DEV-13163
2023-07-17 16:12:56 -04:00
<classify as="@___dsgr_4a8@" />
<classify as="@___dsgr_4ca@" />
<classify as="@___dsgr_4f4@" />
tamer: xmli reconstruction of desugared interpolated metavars Well, this is both good news and bad news. The good news is that this finally produces the expected output and reconstructs sources from interpolated values on the ASG. Yay! ...the bad news is that it's wrong. Notice how the fixpoint test is disabled. So, my plan was originally to commit it like this first and see if I was comfortable relaxing the convention that `<param>` nodes had to appear in the header. That's nice to do, that's cleaner to do, but would the XSLT-based compiler really care? I had to investigate. Well, turns out that TAMER does care. Because, well over a decade ago, I re-used `<param>`, which could represent not only a template param, but also a global param, or a function param. So, XML->NIR considers all `<param>` nodes at the head of a template to be template parameters. But after the first non-header element, we transition to another state that allows it to be pretty much anything. And so, I can't relax that restriction. And because of that, I can't just stream the tree to the xmli generator, I'll have to queue up nodes and order them. Oh well, I tried. DEV-13163
2023-07-13 16:41:27 -04:00
<classify as="@___dsgr_51e@" />
</template>
</package>