Filters (or pipes)

[jgonggrijp]

This is not my own idea, but there was no dedicated ticket for it yet and I thought it deserved one.

@bobthecow gave a semi-formal description of the feature in #41 (comment). He implemented it as described in Mustache.php. There are a few other implementations that include similar features, some of them possibly already before Mustache.php did.

Filters are useful in a variety of common situations that are currently still cumbersome or challenging with standard Mustache:

• Render something once if a list is not empty, even if the list has more than one element. This use case has come up many times, for example in New operator proposal: Conditional block that wont loop when given a list #14, Proposition for a mechanism to add header/footer to sections. #147 and {{#item.0}} checks and context #152.
• Giving special treatment to the first or last element of a list, for example to avoid a trailing comma.
• Accessing the index of the current list element in a section, similar to Handlebars's @index keyword.
• Iterating over a hash/object/dictionary by key/value pairs, similar to Handlebars's #each helper combined with its @key keyword.
• Formatting values such as dates. This should generally already happen before the data are fed to the template, but there are cases where it is undesirable to make all conversions ahead of time, for example if the formatting depends on a condition in the template.
• Testing values for properties other than truthyness, for example whether a number is even or whether a string is a member of some predefined set.

For example, key-value iteration of objects might be implemented using filters, with JavaScript as the host language, as follows.

input data (view)

{
    itemize: function(frame) {
        var pairs = [];
        for (key in frame) {
            pairs.push({key: key, value: frame[key]});
        }
        return pairs;
    },
    favorites: {
        food: 'curry',
        color: 'purple',
        animal: 'cat'
    }
}

template

<dl>
{{# favorites | itemize }}
    <div><dt>{{key}}</dt><dd>{{value}}</dd></div>
{{/ favorites | itemize }}
</dl>

output

<dl>
    <div><dt>food</dt><dd>curry</dd></div>
    <div><dt>color</dt><dd>purple</dd></div>
    <div><dt>animal</dt><dd>cat</dd></div>
</dl>

Here follows a more formal description of my own interpretation of the feature. I have not implemented it yet, but plan to do so in Wontache.

The filters feature would allow you to write multiple dotted names inside interpolation and section tags, separated by pipe symbols:

{{! interpolation example }}
{{ a.b.c | . | p | x.y.z }}

{{! section example }}
{{# q | r }}{{/ q | r }}

Each dotted name (here a.b.c, ., p, x.y.z, q and r) is resolved from the context in the usual way. The leftmost value (a.b.c or q) is used as initial input; the other values should be filters, i.e., functions or methods that take a single argument and return a new value. There are basic fallback rules for when this condition is not met.

The input is fed to the filter directly to its right. The output is reused as input for the filter to the right of the previous filter, until there are no more filters in the chain. The final output is used according to the usual rules for the tag, as if that value had been directly retrieved from the context.

For example, in the example interpolation tag above, the following steps would be taken:

1. a.b.c, . (the implicit iterator), p and x.y.z are retrieved from the context as usual.
2. If a.b.c. does not exist, or if ., p or x.y.z is not a function that accepts a single argument, skip to step 7 with the empty string as the final result.
3. The filter . is applied to the value a.b.c, producing value k.
4. The filter p is applied to the value k, producing value l.
5. The filter x.y.z is applied to the value l, producing value m.
6. m is the final result.
7. The interpolation tag renders with the final result of the previous steps, as if there had been only a single dotted name that directly resolved to that value.

Similarly, for the example section:

1. q and r are retrieved from the context as usual.
2. If q does not exist, or if r is not a function that accepts a single argument, use the empty string as the final result and skip to step 5.
3. The filter r is applied to to the value q, producing value n.
4. n is the final result.
5. The section renders with the final result of the previous steps, as if there had been only a single dotted name that directly resolved to that value.

If the host language supports higher order functions (functions that return functions or function-like objects), then in principle, there is nothing that prevents the last filter in the chain from returning a lambda in the sense of the lambdas extension. This would enable advanced use cases, where a lambda generates a template with knowledge about an arbitrary other value in the context stack. However, it is important to keep in mind that the filters themselves are not lambdas; they might only return lambdas.

Filters and lambdas are both functions (or methods) that are stored in the context along with regular values. There are two key differences:

1. A lambda either receives no argument (if used in an interpolation tag) or a string with the template content of a section (if used in a section tag). A filter always receives a single argument, which is never the template content of a section, but always the value that the template author selected by writing something left of the pipe symbol.
2. If a lambda returns a string and the lambdas extension is implemented, then that string will be rendered as a template. If a filter chain results in a string, it will just be used as a plain string as if that string was directly retrieved from the context. (Note that template overrides can still be achieved by having a filter chain result in a lambda, which then returns a template string.)

[jgonggrijp]

I came up with a small but powerful extension to filters in #154 (comment), which I think would offer an elegant solution to the masking problem. Please see that post for the rationale.

In that post, I wrote that the first filter in the chain receives a list with fallback values as its second argument. I presented it in that way for simplicity, but I think the second argument actually needs to be a special, implementation-defined object that acts as a proxy to such a list. You probably don't want to fully compute the fallback values before the filter is known to actually use any of those values, firstly because it is expensive and secondly, because any resolved value might be a lambda and invoking that lambda might cause side effects.

As a minimal (but sufficient) interface, I suggest that the special object supports a next operation, which either produces the next deeper fallback value, or a special value to indicate that there are no more matches. Of course, implementations can choose to make this interface more convenient, for example by supporting upwards search from the root context or by giving a hint about the number of candidates. An upper bound on the number of candidates is easy to compute with a linear pass over all context frames, by simply looking for the presence of the first key in the dotted name.

I think this flavor of "power filter" would brilliantly complement a flavor of power lambda that only implements the features 4-7 that I listed in #155. Power filters for ultimate stack access, power lambdas for ultimate template control, and the option to return a lambda from a filter to benefit from both at the same time. ❤️

[agentgt]

If a.b.c. does not exist, or if ., p or x.y.z is not a function that accepts a single argument, skip to step 7 with the empty string as the final result.

This gets into implementation specifics but I assume one would need to find all the filters apriori before executing a pipeline? There is no chance the pipeline could affect resolution correct?

The other question is I assume filter sections only push on the stack if they are the last filter? I'm fairly sure that is the case but that might confuse others.

[agentgt]

1. Find foo in the stack, resolve it to a value (e.g. lambdas, etc)
2. Find bar in the stack, ensure that it's callable, pass the result of 1 to it
3. Find baz in the stack, ensure that it's callable, pass the result of 2 to it
4. Thunk the result to string and escape the output

My concern is someone expects that evaluation order and does something side effecty on a short circuit.

Should the spec specify that I guess is the question. Perhaps a best practice could be mentioned to keep filters stateless.

I say this because power lambdas could get very stateful: #155 (reply in thread)

Just to clarify in my implementation none of foo,bar,baz would be executed if any of them are not compliant (e.g. filter ).

In another implementation maybe even on purpose one might rely on foo and bar getting executed even if baz doesn't resolve. I can't figure out for what reason.

[jgonggrijp]

Even non-power lambdas can be stateful, at least in Wontache, through the this binding. So I guess you have a point that this could cause differences in evaluation order to have different end results.

[jgonggrijp]

Rather than specifying the exact evaluation order, we could also specify that an early filter in a pipe should not affect the resolution of filters later in the same pipe. That gives users something to rely on, while allowing implementers freedom to decide whether they resolve all filters before piping or disallow side effects while resolving and calling filters lock-step.

[bobthecow]

tbh i don't hate the idea of resolving all filters before piping any values around, but my general stance is that if you're creating side effects in your filters (or your data) … that's kind of on you?

nothing is stopping a property accessor for something in the stack from messing with global mutable state. even the act of resolving a filter could conceivably mutate state. it's just kind of a bad idea so do it at your own risk :)

[jgonggrijp]

Fair point. Users are in full control of the context. I guess we could also leave these semantics implementation-defined entirely, and instead add a soft recommendation (ha! #164) to leave a warning about side effects in the documentation.

[jgonggrijp]

@agentgt in #164 (reply in thread):

Then you have... well should explain what filters are or what is happening with {{#list | enumerate}}.

I think most people can safely describe first/last/index in less than a paragraph. I don't think filters as they are currently being proposed can be described so easily: #153 (comment)

Perhaps the above will be remedied over time with simpler description but currently it is a lot more than just this key that is available while in a list.

I think the situation with explaining this to end users is not so dire. You refer to a complicated description that I wrote, but it was complicated because it was directed at a critical audience of implementers. End users can generally rely on their intuition, so the description can be much less detailed. I suggest something like the following:

«You may write {{value | filter}} to mean that value and filter must both be resolved in the context, and that filter is a function that will take value as its argument. The return value of filter(value) will be interpolated. You can also pipe through multiple filters before interpolation: {{value | filter | other.filter}}. You can do this in sections as well; the output of the last filter of the chain becomes the current context in that case.»

Of course, there will be end users who just want to get to business and who hate having to learn theory first. As always, you can cater to such users with example code, e.g. "here is how you avoid a trailing comma when separating list items". After the example, you can then write a comment with a link, saying something like «Wonder what that list | enumerate does? See filters».

[jgonggrijp]

@agentgt in #164 (reply in thread):

I'm definitely a fan of filters and can probably get a single | (pipe) working but multiple piping has some evaluation order (e.g. lazy or eager) and static type checking that I may not be able to easily resolve.

I have multiple independent answers to this:

• Don't worry, there is no hurry. As far as I know, I'm the only one who is currently eager to write specs for filters. Even I will not do that before I have implemented filters myself. I currently have no time to work on Wontache, and even when I do, my priorities will be going to some other open issues first. Even when I get around to working on Wontache and implementing filters and writing those specs, there will be a review process and possibly some changes of direction. Even if the review process doesn't take very long and the proposal is accepted, users will not be immediately aware of it. Even when they become aware of it, filters will probably be marked as an optional extension module, so users will know they cannot expect every implementation to fully support them. In other words, users will not be mobbing the JStachio issue tracker with incompatibility complaints any time soon.
• It is fine to deviate a bit from the spec if that makes your implementation easier to maintain or if you can give your users something else in return.
• The composition of two filters is always a new filter. For example, {{# list | size | nonzero }} could be replaced by {{# list | nonempty }}. Hence, if you end up supporting only a single filter per chain, and users need to port templates from another engine, at least they will be able to do it in a way that preserves the exact same output and that will remain portable to other implementations.
• If a feature is really difficult or costly to implement, that might be a reason to not accept it into the spec. I have good hope the situation will not be so bad for filters, though.

[agentgt]

Could you clarify why you think shipping batteries-included filters will be a problem when generating code that does not depend on JStachio?

Because to make it not depend on JStachio I cannot use a decorating object as Java does not have like a builtin class with first/last/index. I could obviously generate a class for every template that does this but that would be waste.

I mean I could probably make it somehow work without using a wrapping object with tons of magic but then it would be this super special intrinsic filter.

As for porting most of the logic that does first and last out there with Mustache-like and regular template languages have the first and last as sibling keys and not children.

The mustache ones implementing first/last as companion / siblings and not wrappers with value:

• Trimou - http://trimou.org/doc/latest.html#variables
• JMustache - https://github.com/samskivert/jmustache#-first-and--last
• JStachio - https://jstach.io/jstachio/#mustache_virtual_keys_iterable
• Handlebars.java - https://handlebarsjs.com/api-reference/data-variables.html#data-variables

Mustache.java is notable in that it is the only implementation that does not have a builtin solution (probably the only templating engine in the java ecosystem as well) and even if we get filters it would still be different enough to not be easy to port.

As for my template snippet I assume you meant:

{{#list | enumerate }}
{{@first}}some first logic{{/first}}
{{@value.name}}
{{/list | enumerate}}

My original template was:

{{#list}}
{{@first}}some first logic{{/first}}
{{name}}
{{/list}}

If I'm doing bulk porting from how almost every other templating engine does first/last to newer filter that decorates (or Mustache.java auto decorate) I can't tell if {{name}} is coming from the list item or something further up. That is decorating with filter does not have the same semantics such that it is an easy search and replace.

And this problem of porting has real world repercussions. The Spring Boot team will unlikely switch from JMustache to @spullara Mustache.java as the default implementation (spring boot will auto pick out templating engines based on stuff) precisely because of backwards compatibility on JMustache -first, -last (and as well as JMustache lambdas).

[jgonggrijp]

Discussion about pragmatism continues here: #163 (comment).

[jgonggrijp]

@agentgt

Could you clarify why you think shipping batteries-included filters will be a problem when generating code that does not depend on JStachio?

Because to make it not depend on JStachio I cannot use a decorating object as Java does not have like a builtin class with first/last/index. I could obviously generate a class for every template that does this but that would be waste.

Isn't that a reasonable cost for type safety? I think if I were using JStachio for that reason, I wouldn't mind having to ship additional classes. Heck, modern C++ is chock full of templates for this very reason.

As for my template snippet I assume you meant:

{{#list | enumerate }}
{{@first}}some first logic{{/first}}
{{@value.name}}
{{/list | enumerate}}

Correct, I forgot the filter.

If I'm doing bulk porting from how almost every other templating engine does first/last to newer filter that decorates (or Mustache.java auto decorate) I can't tell if {{name}} is coming from the list item or something further up. That is decorating with filter does not have the same semantics such that it is an easy search and replace.

I see what you mean. The point of the spec is not to be portable from other templating systems, though. We are only trying to promote portability between Mustache implementations.

Also, having filters in the spec will not prevent you from implementing virtual keys.

[agentgt]

I'll move to #163 after this response:

Isn't that a reasonable cost for type safety? I think if I were using JStachio for that reason, I wouldn't mind having to ship additional classes. Heck, modern C++ is chock full of templates for this very reason.

In the java world because of various reason.... it is a long complicated topic similar to DLL hell but yes I could ship with something as JStachio does have an optional runtime and most use it for web applications. It does still require object allocation vs just passing around natives but performance across implementations is too variable that my pain point on that should not impact spec.

Also, having filters in the spec will not prevent you from implementing virtual keys.

I'm not sure if I mentioned it before but my wanting of virtual keys "best practice" is kind of exclusive and independent of filters.

In fact they largely compliment each other (e.g. {{#@index | isEven}}.

Without a doubt filters are way more powerful than virtual keys and can largely simulate what virtual keys do.

Also unlike virtual keys filters absolutely need to be spec-ed.

In irony if Mustache was not aimed at being so logicless then I would actually prefer filters more than virtual keys as it is clearly more powerful.

So I'm conflicted on that front.

I know I seem contentious on filters but I am just doing my diligence to kill all doubts at least in my mind.

Also I have gone the purist route before with bad results... I guess this time in the words of Tron: "I fight for the user!".

Anyway your right that this convo is better for #163

[jgonggrijp]

(...) filters absolutely need to be spec-ed.

Music to my eyes!

In irony if Mustache was not aimed at being so logicless then I would actually prefer filters more than virtual keys as it is clearly more powerful.

So I'm conflicted on that front.

Good point on the irony. If it helps, @index, @first and @last don't seem entirely logicless to me, either. I mean, if those are virtual keys, then they apparently appear out of thin air because I did a {{#list}}. That seems more logic-y to me than only being able to iterate over the elements in their raw forms.

I know I seem contentious on filters but I am just doing my diligence to kill all doubts at least in my mind.

I wrote this before, but: no problem. In fact, please keep it coming. No harm can be done by exploring all the weak spots of a proposal.

Also I have gone the purist route before with bad results...

You mentioned XSLT and one other system before. Is that what you are referring to here as well? What went wrong?

[jgonggrijp]

@agentgt in #163 (reply in thread):

I like Mustache because it is syntactically minimal but I really like it because it is safe and can be made even safer (as shown with JStachio).

I don't consider current lambdas that create the templates on the fly safe. Filters I do a little bit more but I don't like the return "" if it fails.

What would you prefer to happen if it fails?

I don't really have a problem with filters doing enumeration to handle the problem. I have a problem in that it is unlikely an agreed standard filter that does enumeration would be included. It is unlikely I can make it performant compared to the current virtual keys. It is unlikely I can make it decoupled from JStachio.

Are these reasons to be opposed to filters in general? What stops you from giving users an alternative that you feel is superior?

Also I just wanted to make sure we know all the limitations to using the enumeration filter approach so that we can express that to ... again users.

Yes, you are doing a good job at that (I mean it). The mental notes I've made so far are:

• Users will likely need to port an enumeration filter from one implementation to another in order to continue using their templates unmodified (this is true of all filters and lambdas, but it is still a limitation for enumeration as well).
• There needs to be a code example in the documentation demonstrating how to use it.
• If the implementation has a trick to enable shortcuts like {{.}}, then the documentation should mention that the equivalent non-shortcut notation ({{@value}} or similar) is likely to be better portable to other Mustache implementations.

[jgonggrijp]

@agentgt in #163 (reply in thread):

I'm almost fully on board with filters. While I would like to keep Mustache as simple as possible and while I agree with @jgonggrijp that it has served people well for 15 years that doesn't mean the language can or should not grow.

(...)

Anyway I think filters are needed to keep the language growing whether that is by new users or new problems. (...)

What is still missing to get you fully on board?

[agentgt]

Implementing it of course. (Prototype).

I’m fairly sure there will be no problems other than perhaps some issues with generics.

I do have it mostly implemented but with ".".

[agentgt]

@jgonggrijp I guess the only thing I currently do not like is the name "filter" 😄 . Naming the classic bikeshed.

In the Java world the current | power filter would be called map and many other languages follow a similar name. Filter in java implies a boolean return.

Also the term "filter" was used in the manual with lambda and it implied more of a textual filter (see below).

An optional part of the specification states that if the final key in the name is a lambda that returns a string, then that string replaces the content of the section. It will be rendered using the same delimiters (see Set Delimiter below) as the original section content. In this way you can implement filters or caching.

Unfortunately map is pretty overloaded.

So for me I'm currently thinking in order of preference:

1. "Pipe"
2. "Map"
3. "Function"
4. "Power Lambda' .. yes we could just call it a better lambda and discard the current notions of power lambdas.
5. "Lambda" and just explain another optional part.

I suppose if we kept "filter", I would recommend removing this sentence:

In this way you can implement filters or caching.

[jgonggrijp]

My take:

0. filter - I agree that sentence in the manual will be confusing, but I think that is just a matter of removing or changing the sentence. No need to abandon the whole name just because of that.
1. pipe - sure, works too
2. map - already too overloaded as you wrote
3. function - suggests way more power than filters actually have
4. power lambda - this is not a better lambda, it lacks most of the functionality of current lambdas
5. lambda - maybe, but I feel it creates too much room for confusion between two types of lambda

[agentgt]

If we have interpolation filters it makes more sense that they are called filters. I think I just kept thinking about the section filter.

[agentgt]

On a separate issue (hence top level comment) do we need non-section aka binding filters?

1. {{stuff | filter}} - binding filter
2. {{#stuff | filter }} {{/stuff | filter}} - section filter

I obviously see how binding filters could be useful but I think section filters can largely do what binding filters do or am I missing something?

[jgonggrijp]

Yes I think we need both. With only section filters, simple things like {{ someString | capitalize }} or {{ someList | size }} would get needlessly verbose.

[agentgt]

I guess my concern other than the whole strive for minimal thing is confusion on overloading.

That is someone could make capitalize take a list of strings and transform that entire list as well as the single case.

This kind of gets in the best practice and implementation details.

That is in some languages like Javascript having a function that takes a single item (string in this case) and a list is just a pattern of detecting input type. The a single capitalize could handle a list of strings (section) and single string (interpolation).

In some other languages the above may not be possible. Technically in Java it is with method overloading and I just have to figure out which correct method to call.

See before if you had some form of lambda taking top of stack it was never a list as it wasn't possible to syntactically express that w/ top of stack access (e.g. lambda take this list).

Probably just need to be mindful of the above if we offer builtins or recommendations on how to implement filters. Make list filters only do lists.

EDIT I suppose the above is kind of independent of whether interpolation filters exist.

[jgonggrijp]

Two things:

• "Lambda takes top of stack" was never a standard thing. JStachio does that and maybe some other implementations, but lambdas are actually supposed to either receive no argument at all (for interpolation) or the content of a section.
• JStachio already faces overloading, because lambdas can also receive the thing before them in a dotted name. Compare {{#list}}{{lambda}}{{/list}} and {{list.lambda}}.

However, you do have a point that overloading could complicate portability.

[agentgt]

"Lambda takes top of stack" was never a standard thing. JStachio does that and maybe some other implementations, but lambdas are actually supposed to either receive no argument at all (for interpolation) or the content of a section.

Yeah I get that. I meant I never anticipated lists getting passed.

The reason is one could choose an implementation where a list always gets passed. An interpolation call would get a list with one item.

However the more I think about that the more I realize how dumb that is.

That is I plan on failing if one calls

@Filter
public List<String> capitalize(List<String> list) {}

{{singleString | capitalize}}

Because singleString is not a list.

I know other implementations will do the whole empty string thing but I make that configurable.

JStachio already faces overloading, because lambdas can also receive the thing before them in a dotted name. Compare {{#list}}{{lambda}}{{/list}} and {{list.lambda}}.

Yes there is that but I meant a different overloading in terms of registration.

e.g.

// Assume both methods on same object type
@Filter
public List<String> capitalize(List<String> list) {}
// vs
@Filter
public String capitalize(String list) {}

Right now I think one arbitrarily gets picked up and then fails if the contract is wrong. I just have to figure out whether I allow the above (e.g. two filter registrations).

The above was far less likely to happen than before. The reason is regular interpolation lambdas in JStachio would be just method calls but I can't allow dynamic templates so that is why they are absent.

But now we have both forms (interpolation and section) and both can take a single item or list.

Anyway I'm fairly sure I have all my bases covered and just wanted to talk it one more time before I make the prototype.

[jgonggrijp]

Something that would also have to be addressed in an eventual filters specification, is how pipes interact with dynamic names. For the first time, I just encountered a situation where I might want to use both within a single tag in #178 (reply in thread), where I wrote {{>* level | loglevel }}.

In #134, it was agreed that dots take precedence over dereference, so *a.b means *(a.b) and not (*a).b. In fact, doing something like a.*b would not be allowed.

The filters proposal as discussed here, implies that dots also take precedence over pipes.

Hence, dots take the highest precedence, and the question remains whether pipes precede over dereference or the other way round.

In #134 (comment), @bobthecow suggested that dereference would take higher precedence, so it would be possible and allowed to write *a.b | *c.d meaning (*(a.b)) | (*(c.d)).

Today in #178 (reply in thread), I assumed the opposite precedence: *a.b | *c.d not being allowed and * a.b | c.d meaning *((a.b) | (c.d)). I think I prefer that, for two reasons:

1. It simplifies cases like {{>* level | loglevel }} in Fallthrough sections #178 (reply in thread), where a filter is evaluated in order to determine the name of a template. If dereference took precedence over pipes, I would have to write {{> level | *loglevel }}, which I find less clear and less intuitive. In fact, I think that should mean something else (if allowed): dereference loglevel before piping level through it.
2. I somewhat feel that the dereference notation should stay at the front of the tag and only apply to the entire tag contents. That is, regardless of what tag-internal operators might exist in the future, {{>* insert.anything|with+operators?in#here }} should always keep its relatively simply meaning of {{> {{insert.anything|with+operators?in#here}} }}. I don't want to turn the template language into some kind of circus where you can make crazy lookup jumps like {{ {{a.b}} | {{c.d}} | {{e.f}} }}.

In other words, I probably think that when pipes or other operators come into the picture, the * dynamic name notation should behave more like a tag modifier than a full-fledged operator, or if it is an operator, as one that has bottom precedence.

Thoughts?

[agentgt]

My gut is that pipes | should take precedence over *.

That is I see this happening quite a bit with JStachio once I implement: jstachio/jstachio#140

{{>* item | resolveTemplateEnumFilter }}

However JStachio will only ever support dynamic partial names (it isn't actually a template name but a symbol that represents the template).

I think that regular dynamic names are way too complicated and not logicless so seeing something like (parens just added for clarification):

{{ (*a.b) | (*c.d) }}

Incredibly confusing. I would even make the argument that perhaps dynamic names should not be supported in pipes other than the first parameter (e.g. applied to the final result of the filter pipe).

[agentgt]

@bobthecow @jgonggrijp

What are your thoughts on allowing the last name/key on a pipe to be a lambda?

An example might be for i18n (gettext style).

{{# blah | preprocess | i18n }}
Hello {{name}}!
{{/ blah | preprocess | i18n }}

My only issue is that I can't figure out how dynamic implementations particularly Javascript can disambiguate lambda calls from power filter so that you pass the section body and not the previous output.

Then again it is just ergonomics and this is not really that much more typing:

{{# blah | preprocess}}
{{#i18n}}
Hello {{name}}!
{{/i18n}}
{{/ blah | preprocess}}

[jgonggrijp]

I think higher order functions solve the problem. In your example, i18n would be a filter that returns a lambda. i18n itself receives the result of preprocess. It then returns a callable object (obviously a method, in Java). The latter receives the Hello {{name}}! section contents as its first argument. It might also still have access to the information that i18n received, if i18n passed that information to the constructor of the class of which the lambda is a method. Finally, the lamdba is either going to push a new frame on the stack or override the template (or possibly both, if you have more-powerful lambdas).

I previously illustrated this approach in #155 (reply in thread).

Aside: I noticed that you tend to write "power filters". I think you mean to refer to regular filters most of the time. That is, the idea I described in the opening post (or something similar) is just regular filters. I coined "power filters" for a variant where a second argument to the filter unlocks the ability to deviate from the masking rules. See #153 (comment) and #154 (comment).

[agentgt]

I think higher order functions solve the problem.

You had me on higher order... damn Java poisoned my mind :) I forgot it totally makes since and in theory it should just work.

Aside: I noticed that you tend to write "power filters". I think you mean to refer to regular filters most of the time

Correct. I mean filters. I am not sure why I kept writing that. 😄

I think in this case I was thinking that it would be some optional extension to filters similar to optional extension to lambdas and thus needed the modifier "power" but to be honest I'm not sure what I was thinking.