2023-03-09 09:19:05 -05:00
|
|
|
|
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">
|
|
|
|
|
2023-04-12 15:53:16 -04:00
|
|
|
<template name="_empty_" desc="Empty" />
|
2023-03-08 23:49:03 -05:00
|
|
|
|
2023-04-12 15:53:16 -04:00
|
|
|
<template name="_with-static-identified_"
|
|
|
|
desc="Template with identified expressions">
|
2023-03-08 14:47:31 -05:00
|
|
|
<rate yields="tplStaticA">
|
|
|
|
<c:sum />
|
|
|
|
</rate>
|
|
|
|
<classify as="tpl-static-b">
|
|
|
|
<any />
|
|
|
|
</classify>
|
|
|
|
</template>
|
2023-03-08 23:44:40 -05:00
|
|
|
|
2023-04-12 15:53:16 -04:00
|
|
|
<template name="_with-static-unidentified_"
|
|
|
|
desc="Unidentified expressions in body">
|
2023-03-08 23:44:40 -05:00
|
|
|
<c:sum>
|
|
|
|
<c:product />
|
|
|
|
</c:sum>
|
|
|
|
</template>
|
|
|
|
|
2023-04-12 15:53:16 -04:00
|
|
|
<template name="_with-static-mix_"
|
|
|
|
desc="Both identified and unidentified that may or may
|
|
|
|
not be reachable in expansion context">
|
2023-03-08 23:44:40 -05:00
|
|
|
<c:product>
|
|
|
|
<c:sum />
|
|
|
|
</c:product>
|
|
|
|
|
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
|
|
|
|
|
|
|
|
2023-03-08 23:44:40 -05:00
|
|
|
<rate yields="tplStaticMix" />
|
|
|
|
|
tamer: asg::air::object::tpl: Reject multi-expression shape
This enforces the new constraint that templates expanding into an `Expr`
context must only inline a single `Expr`.
Perhaps in the future we'll support explicit splicing, like `,@` in
Lisp. But this new restriction is intended for two purposes:
- To make templates more predictable (if you have a list of expressions
inlined then they will act differently depending on the type of
expression that they are inlined into, which means that more defensive
programming would otherwise be required); and
- To make expansion easier, since we're going to have to set aside an
expansion workspace ahead of time to ensure ordering (Petgraph can't
replace edges in-place). If we support multi-expansion, we'd have to
handle associativity in all expression contexts.
This'll become more clear in future commits.
It's nice to see all this hard work coming together now, though; it's easy
now to perform static analysis on the system, and any part of the graph
construction can throw errors with rich diagnostic information and still
recover properly. And, importantly, the system enforces its own state, and
the compiler helps us with that (the previous commits).
DEV-13163
2023-07-26 03:43:24 -04:00
|
|
|
<rate yields="tplStaticMixEnd">
|
2023-03-08 23:44:40 -05:00
|
|
|
<c:product />
|
tamer: asg::air::object::tpl: Reject multi-expression shape
This enforces the new constraint that templates expanding into an `Expr`
context must only inline a single `Expr`.
Perhaps in the future we'll support explicit splicing, like `,@` in
Lisp. But this new restriction is intended for two purposes:
- To make templates more predictable (if you have a list of expressions
inlined then they will act differently depending on the type of
expression that they are inlined into, which means that more defensive
programming would otherwise be required); and
- To make expansion easier, since we're going to have to set aside an
expansion workspace ahead of time to ensure ordering (Petgraph can't
replace edges in-place). If we support multi-expansion, we'd have to
handle associativity in all expression contexts.
This'll become more clear in future commits.
It's nice to see all this hard work coming together now, though; it's easy
now to perform static analysis on the system, and any part of the graph
construction can throw errors with rich diagnostic information and still
recover properly. And, importantly, the system enforces its own state, and
the compiler helps us with that (the previous commits).
DEV-13163
2023-07-26 03:43:24 -04:00
|
|
|
</rate>
|
2023-03-08 23:44:40 -05:00
|
|
|
</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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-04-12 15:53:16 -04:00
|
|
|
<template name="_short-hand-nullary_" desc="No params" />
|
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_" />
|
2023-03-23 00:04:53 -04:00
|
|
|
|
2023-04-12 15:53:16 -04:00
|
|
|
<template name="_short-hand-unary_" desc="One param" />
|
2023-03-23 00:04:53 -04:00
|
|
|
<apply-template name="_short-hand-unary_">
|
|
|
|
<with-param name="@foo@" value="bar" />
|
|
|
|
</apply-template>
|
|
|
|
|
2023-04-12 15:53:16 -04:00
|
|
|
<template name="_short-hand-nary_" desc="N params" />
|
2023-03-23 00:04:53 -04:00
|
|
|
<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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-04-12 15:53:16 -04:00
|
|
|
<template name="_short-hand-nullary-body_" desc="Nullary with body" />
|
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
|
|
|
<apply-template name="_short-hand-nullary-body_">
|
tamer: asg::air::object::tpl: Reject multi-expression shape
This enforces the new constraint that templates expanding into an `Expr`
context must only inline a single `Expr`.
Perhaps in the future we'll support explicit splicing, like `,@` in
Lisp. But this new restriction is intended for two purposes:
- To make templates more predictable (if you have a list of expressions
inlined then they will act differently depending on the type of
expression that they are inlined into, which means that more defensive
programming would otherwise be required); and
- To make expansion easier, since we're going to have to set aside an
expansion workspace ahead of time to ensure ordering (Petgraph can't
replace edges in-place). If we support multi-expansion, we'd have to
handle associativity in all expression contexts.
This'll become more clear in future commits.
It's nice to see all this hard work coming together now, though; it's easy
now to perform static analysis on the system, and any part of the graph
construction can throw errors with rich diagnostic information and still
recover properly. And, importantly, the system enforces its own state, and
the compiler helps us with that (the previous commits).
DEV-13163
2023-07-26 03:43:24 -04:00
|
|
|
<with-param name="@values@" value="___dsgr-bb5___" />
|
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
|
|
|
</apply-template>
|
tamer: asg::air::object::tpl: Reject multi-expression shape
This enforces the new constraint that templates expanding into an `Expr`
context must only inline a single `Expr`.
Perhaps in the future we'll support explicit splicing, like `,@` in
Lisp. But this new restriction is intended for two purposes:
- To make templates more predictable (if you have a list of expressions
inlined then they will act differently depending on the type of
expression that they are inlined into, which means that more defensive
programming would otherwise be required); and
- To make expansion easier, since we're going to have to set aside an
expansion workspace ahead of time to ensure ordering (Petgraph can't
replace edges in-place). If we support multi-expansion, we'd have to
handle associativity in all expression contexts.
This'll become more clear in future commits.
It's nice to see all this hard work coming together now, though; it's easy
now to perform static analysis on the system, and any part of the graph
construction can throw errors with rich diagnostic information and still
recover properly. And, importantly, the system enforces its own state, and
the compiler helps us with that (the previous commits).
DEV-13163
2023-07-26 03:43:24 -04:00
|
|
|
<template name="___dsgr-bb5___"
|
2023-04-13 09:30:27 -04:00
|
|
|
desc="Desugared body of shorthand template application of `_short-hand-nullary-body_`">
|
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
|
|
|
<c:product>
|
|
|
|
<c:sum />
|
|
|
|
</c:product>
|
|
|
|
</template>
|
|
|
|
|
2023-04-12 15:53:16 -04:00
|
|
|
<template name="_short-hand-nary-body_" desc="N-ary with body" />
|
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
|
|
|
<apply-template name="_short-hand-nary-body_">
|
|
|
|
<with-param name="@bar@" value="baz" />
|
|
|
|
<with-param name="@baz@" value="quux" />
|
tamer: asg::air::object::tpl: Reject multi-expression shape
This enforces the new constraint that templates expanding into an `Expr`
context must only inline a single `Expr`.
Perhaps in the future we'll support explicit splicing, like `,@` in
Lisp. But this new restriction is intended for two purposes:
- To make templates more predictable (if you have a list of expressions
inlined then they will act differently depending on the type of
expression that they are inlined into, which means that more defensive
programming would otherwise be required); and
- To make expansion easier, since we're going to have to set aside an
expansion workspace ahead of time to ensure ordering (Petgraph can't
replace edges in-place). If we support multi-expansion, we'd have to
handle associativity in all expression contexts.
This'll become more clear in future commits.
It's nice to see all this hard work coming together now, though; it's easy
now to perform static analysis on the system, and any part of the graph
construction can throw errors with rich diagnostic information and still
recover properly. And, importantly, the system enforces its own state, and
the compiler helps us with that (the previous commits).
DEV-13163
2023-07-26 03:43:24 -04:00
|
|
|
<with-param name="@values@" value="___dsgr-c6c___" />
|
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
|
|
|
</apply-template>
|
tamer: asg::air::object::tpl: Reject multi-expression shape
This enforces the new constraint that templates expanding into an `Expr`
context must only inline a single `Expr`.
Perhaps in the future we'll support explicit splicing, like `,@` in
Lisp. But this new restriction is intended for two purposes:
- To make templates more predictable (if you have a list of expressions
inlined then they will act differently depending on the type of
expression that they are inlined into, which means that more defensive
programming would otherwise be required); and
- To make expansion easier, since we're going to have to set aside an
expansion workspace ahead of time to ensure ordering (Petgraph can't
replace edges in-place). If we support multi-expansion, we'd have to
handle associativity in all expression contexts.
This'll become more clear in future commits.
It's nice to see all this hard work coming together now, though; it's easy
now to perform static analysis on the system, and any part of the graph
construction can throw errors with rich diagnostic information and still
recover properly. And, importantly, the system enforces its own state, and
the compiler helps us with that (the previous commits).
DEV-13163
2023-07-26 03:43:24 -04:00
|
|
|
<template name="___dsgr-c6c___"
|
2023-04-13 09:30:27 -04:00
|
|
|
desc="Desugared body of shorthand template application of `_short-hand-nary-body_`">
|
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
|
|
|
<c:sum>
|
|
|
|
<c:product />
|
|
|
|
</c:sum>
|
|
|
|
</template>
|
2023-04-05 10:45:54 -04:00
|
|
|
|
2023-04-12 15:53:16 -04:00
|
|
|
<template name="_short-hand-nullary-outer_"
|
|
|
|
desc="Outer template holding an inner" />
|
2023-04-05 10:45:54 -04:00
|
|
|
<apply-template name="_short-hand-nullary-outer_">
|
tamer: asg::air::object::tpl: Reject multi-expression shape
This enforces the new constraint that templates expanding into an `Expr`
context must only inline a single `Expr`.
Perhaps in the future we'll support explicit splicing, like `,@` in
Lisp. But this new restriction is intended for two purposes:
- To make templates more predictable (if you have a list of expressions
inlined then they will act differently depending on the type of
expression that they are inlined into, which means that more defensive
programming would otherwise be required); and
- To make expansion easier, since we're going to have to set aside an
expansion workspace ahead of time to ensure ordering (Petgraph can't
replace edges in-place). If we support multi-expansion, we'd have to
handle associativity in all expression contexts.
This'll become more clear in future commits.
It's nice to see all this hard work coming together now, though; it's easy
now to perform static analysis on the system, and any part of the graph
construction can throw errors with rich diagnostic information and still
recover properly. And, importantly, the system enforces its own state, and
the compiler helps us with that (the previous commits).
DEV-13163
2023-07-26 03:43:24 -04:00
|
|
|
<with-param name="@values@" value="___dsgr-d50___" />
|
2023-04-05 10:45:54 -04:00
|
|
|
</apply-template>
|
tamer: asg::air::object::tpl: Reject multi-expression shape
This enforces the new constraint that templates expanding into an `Expr`
context must only inline a single `Expr`.
Perhaps in the future we'll support explicit splicing, like `,@` in
Lisp. But this new restriction is intended for two purposes:
- To make templates more predictable (if you have a list of expressions
inlined then they will act differently depending on the type of
expression that they are inlined into, which means that more defensive
programming would otherwise be required); and
- To make expansion easier, since we're going to have to set aside an
expansion workspace ahead of time to ensure ordering (Petgraph can't
replace edges in-place). If we support multi-expansion, we'd have to
handle associativity in all expression contexts.
This'll become more clear in future commits.
It's nice to see all this hard work coming together now, though; it's easy
now to perform static analysis on the system, and any part of the graph
construction can throw errors with rich diagnostic information and still
recover properly. And, importantly, the system enforces its own state, and
the compiler helps us with that (the previous commits).
DEV-13163
2023-07-26 03:43:24 -04:00
|
|
|
<template name="___dsgr-d50___"
|
2023-04-13 09:30:27 -04:00
|
|
|
desc="Desugared body of shorthand template application of `_short-hand-nullary-outer_`">
|
2023-04-12 15:53:16 -04:00
|
|
|
<template name="_short-hand-nullary-inner-dfn-inner_"
|
|
|
|
desc="Inner template applied inner" />
|
2023-04-05 10:45:54 -04:00
|
|
|
<apply-template name="_short-hand-nullary-inner-dfn-inner_" />
|
|
|
|
</template>
|
|
|
|
|
2023-04-12 15:53:16 -04:00
|
|
|
<template name="_short-hand-nullary-inner-dfn-outer_"
|
|
|
|
desc="Define template outer but apply inner" />
|
2023-04-05 10:45:54 -04:00
|
|
|
<apply-template name="_short-hand-nullary-outer_">
|
tamer: asg::air::object::tpl: Reject multi-expression shape
This enforces the new constraint that templates expanding into an `Expr`
context must only inline a single `Expr`.
Perhaps in the future we'll support explicit splicing, like `,@` in
Lisp. But this new restriction is intended for two purposes:
- To make templates more predictable (if you have a list of expressions
inlined then they will act differently depending on the type of
expression that they are inlined into, which means that more defensive
programming would otherwise be required); and
- To make expansion easier, since we're going to have to set aside an
expansion workspace ahead of time to ensure ordering (Petgraph can't
replace edges in-place). If we support multi-expansion, we'd have to
handle associativity in all expression contexts.
This'll become more clear in future commits.
It's nice to see all this hard work coming together now, though; it's easy
now to perform static analysis on the system, and any part of the graph
construction can throw errors with rich diagnostic information and still
recover properly. And, importantly, the system enforces its own state, and
the compiler helps us with that (the previous commits).
DEV-13163
2023-07-26 03:43:24 -04:00
|
|
|
<with-param name="@values@" value="___dsgr-ea4___" />
|
2023-04-05 10:45:54 -04:00
|
|
|
</apply-template>
|
tamer: asg::air::object::tpl: Reject multi-expression shape
This enforces the new constraint that templates expanding into an `Expr`
context must only inline a single `Expr`.
Perhaps in the future we'll support explicit splicing, like `,@` in
Lisp. But this new restriction is intended for two purposes:
- To make templates more predictable (if you have a list of expressions
inlined then they will act differently depending on the type of
expression that they are inlined into, which means that more defensive
programming would otherwise be required); and
- To make expansion easier, since we're going to have to set aside an
expansion workspace ahead of time to ensure ordering (Petgraph can't
replace edges in-place). If we support multi-expansion, we'd have to
handle associativity in all expression contexts.
This'll become more clear in future commits.
It's nice to see all this hard work coming together now, though; it's easy
now to perform static analysis on the system, and any part of the graph
construction can throw errors with rich diagnostic information and still
recover properly. And, importantly, the system enforces its own state, and
the compiler helps us with that (the previous commits).
DEV-13163
2023-07-26 03:43:24 -04:00
|
|
|
<template name="___dsgr-ea4___"
|
2023-04-13 09:30:27 -04:00
|
|
|
desc="Desugared body of shorthand template application of `_short-hand-nullary-outer_`">
|
2023-04-05 10:45:54 -04:00
|
|
|
<apply-template name="_short-hand-nullary-inner-dfn-outer_" />
|
|
|
|
</template>
|
|
|
|
|
2023-04-12 15:53:16 -04:00
|
|
|
<template name="_short-hand-unary-with-body_"
|
|
|
|
desc="Unary with body" />
|
|
|
|
<apply-template name="_short-hand-unary-with-body_">
|
2023-04-05 10:45:54 -04:00
|
|
|
<with-param name="@foo@" value="bar" />
|
tamer: asg::air::object::tpl: Reject multi-expression shape
This enforces the new constraint that templates expanding into an `Expr`
context must only inline a single `Expr`.
Perhaps in the future we'll support explicit splicing, like `,@` in
Lisp. But this new restriction is intended for two purposes:
- To make templates more predictable (if you have a list of expressions
inlined then they will act differently depending on the type of
expression that they are inlined into, which means that more defensive
programming would otherwise be required); and
- To make expansion easier, since we're going to have to set aside an
expansion workspace ahead of time to ensure ordering (Petgraph can't
replace edges in-place). If we support multi-expansion, we'd have to
handle associativity in all expression contexts.
This'll become more clear in future commits.
It's nice to see all this hard work coming together now, though; it's easy
now to perform static analysis on the system, and any part of the graph
construction can throw errors with rich diagnostic information and still
recover properly. And, importantly, the system enforces its own state, and
the compiler helps us with that (the previous commits).
DEV-13163
2023-07-26 03:43:24 -04:00
|
|
|
<with-param name="@values@" value="___dsgr-f6b___" />
|
2023-04-05 10:45:54 -04:00
|
|
|
</apply-template>
|
tamer: asg::air::object::tpl: Reject multi-expression shape
This enforces the new constraint that templates expanding into an `Expr`
context must only inline a single `Expr`.
Perhaps in the future we'll support explicit splicing, like `,@` in
Lisp. But this new restriction is intended for two purposes:
- To make templates more predictable (if you have a list of expressions
inlined then they will act differently depending on the type of
expression that they are inlined into, which means that more defensive
programming would otherwise be required); and
- To make expansion easier, since we're going to have to set aside an
expansion workspace ahead of time to ensure ordering (Petgraph can't
replace edges in-place). If we support multi-expansion, we'd have to
handle associativity in all expression contexts.
This'll become more clear in future commits.
It's nice to see all this hard work coming together now, though; it's easy
now to perform static analysis on the system, and any part of the graph
construction can throw errors with rich diagnostic information and still
recover properly. And, importantly, the system enforces its own state, and
the compiler helps us with that (the previous commits).
DEV-13163
2023-07-26 03:43:24 -04:00
|
|
|
<template name="___dsgr-f6b___"
|
2023-04-13 09:30:27 -04:00
|
|
|
desc="Desugared body of shorthand template application of `_short-hand-unary-with-body_`">
|
2023-04-12 15:53:16 -04:00
|
|
|
<template name="_short-hand-unary-with-body-inner_"
|
|
|
|
desc="Inner template" />
|
|
|
|
<apply-template name="_short-hand-unary-with-body-inner_" />
|
2023-04-05 10:45:54 -04:00
|
|
|
</template>
|
2023-04-05 14:21:56 -04:00
|
|
|
|
2023-04-12 15:53:16 -04:00
|
|
|
<template name="_short-hand-in-expr_"
|
|
|
|
desc="Template to be applied within an expression" />
|
2023-04-05 14:21:56 -04:00
|
|
|
<rate yields="shortHandTplInExpr">
|
|
|
|
<apply-template name="_short-hand-in-expr_">
|
|
|
|
<with-param name="@in@" value="rate" />
|
|
|
|
</apply-template>
|
|
|
|
</rate>
|
|
|
|
|
2023-04-12 15:53:16 -04:00
|
|
|
<template name="_tpl-with-short-hand-inner_"
|
|
|
|
desc="Template with a shorthand application in its body">
|
2023-04-05 14:21:56 -04:00
|
|
|
<template name="_tpl-with-short-hand-inner-inner_" />
|
|
|
|
<apply-template name="_tpl-with-short-hand-inner-inner_" />
|
|
|
|
|
|
|
|
<c:sum>
|
|
|
|
<apply-template name="_tpl-with-short-hand-inner-inner_">
|
|
|
|
<with-param name="@in@" value="sum" />
|
|
|
|
</apply-template>
|
|
|
|
</c:sum>
|
|
|
|
</template>
|
2023-04-06 14:31:06 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-04-12 15:53:16 -04:00
|
|
|
<template name="_match-child_" desc="Template with a match child">
|
2023-04-06 14:31:06 -04:00
|
|
|
<match on="foo" value="TRUE" />
|
|
|
|
</template>
|
2023-06-14 16:38:05 -04:00
|
|
|
|
|
|
|
<template name="_tpl-param_" desc="Template with a param">
|
|
|
|
<param name="@foo@" desc="A parameter" />
|
|
|
|
<param name="@bar@" desc="Another parameter" />
|
|
|
|
</template>
|
2023-07-18 12:31:28 -04:00
|
|
|
|
|
|
|
|
|
|
|
<template name="_tpl-param_body_"
|
|
|
|
desc="Template with params with bodies">
|
|
|
|
<param name="@text@" desc="A param with a literal">
|
|
|
|
<text>lonely foo</text>
|
|
|
|
</param>
|
|
|
|
|
|
|
|
<param name="@ref@" desc="A param with a ref">
|
|
|
|
<param-value name="@text@" />
|
|
|
|
</param>
|
|
|
|
|
|
|
|
<param name="@both@" desc="A param with both literal and ref">
|
|
|
|
<text>foo </text>
|
|
|
|
<param-value name="@text@" />
|
|
|
|
<text> bar</text>
|
|
|
|
</param>
|
|
|
|
</template>
|
2023-02-24 23:01:02 -05:00
|
|
|
</package>
|
2023-03-09 09:19:05 -05:00
|
|
|
|