[stringtemplate-interest] StringTemplate Compiler for .NET

[Terence Parr]

On Mar 21, 2009, at 12:07 PM, Sam Harwell wrote:

> This email describes a proposal that I'm absolutely willing to
> implement. As I mention at the end, I'm very interested in feedback on
> the idea as will.
>
> Before I work to optimize handling of various cases, I'm modifying
> StringTemplate to have a Frozen (immutable) state. Before the object  
> is
> frozen, a call to ToString() will internally call GetAsFrozen()
> (actually not quite; see #4 below) to get a frozen duplicate of the
> current template, and evaluate ToString() on it. A warning will
> optionally be issued to stderr when this case occurs.
>
> When a template is frozen, all attributes are locked and the  
> expression
> tree is compiled.

That's the same as evaluating it to a string so why not just do that?  
you can cache the string instead of compiling.

> However, a subsequent call to Clone will return an
> non-frozen copy of the template with no attributes set. The advantage
> comes from several key characteristics of the cloned copies:
>
> 1. The clone gets a copy of the compiled expression tree. As long as  
> the
> pattern is not changed, the expression tree will not need recompiling
> before evaluation. The calls to Freeze or GetAsFrozen will simply lock
> the attribute set.

  expression trees never change, do they?

> 2. When the expression tree is compiled, a List of objects is created
> with a bucket for every referenced attribute of every template. When
> SetAttribute is called, the value is placed immediately in the proper
> bin for direct lookup during evaluation. Otherwise, it goes in the
> dictionary and the values are placed in bins after the expression is
> compiled.
>
> 3. If a never-frozen template is cloned, the non-compiled template is
> copied on write. This means if *either* copy is frozen, both copies  
> will
> get the expression tree and bin layout. The frozen copy will move
> attributes to the bins immediately; the other will copy them when it  
> is
> frozen later, but it won't have to recomputed the bins.
>
> 4. Calls to GetAsFrozen copy all frozen subtemplates by reference. Two
> additional methods, CloneCurrentValue and GetCurrentValueAsFrozen,
> return copies including all current attributes. Clearly a call to
> GetCurrentValueAsFrozen on a frozen template will simply "return  
> this;",
> and a call to Freeze on a frozen template will immediately return.  
> With
> that said, a call to ToString on a non-frozen template will actually
> call GetCurrentValueAsFrozen. :)
>
> It's my opinion (open to suggestions) that this implementation is
> appropriate for the following reasons:
>
> A. It's conceptually straightforward and therefore straightforward to
> implement.
> B. It addresses all remaining bottlenecks that have been described  
> here
> on the list.
> C. It offers excellent performance for a variety of uses/order of
> operations. It's easy to add runtime warnings for performance- 
> degrading
> uses such as calls to ToString() on non-frozen templates while
> simultaneously holding on to the compiled expression so the  
> performance
> is strong on later calls to ToString() on that same template.
> D. Since the concept is not reliant on either the template compilation
> method or syntax/built-in functions/features of the StringTemplate
> language itself, it will be portable to version 4. We've also already
> shown that multiple compilation techniques can be used targeting the
> CLI, and I imagine similar could be done in Java (jealous of our  
> lambdas
> yet? =) ).

Still not sure what frozen means. sorry.

Does any of this break the lazy evaluation?

Ter