[stringtemplate-interest] StringTemplate Compiler for .NET

[Sam Harwell]

Compiling the expression tree allows heavy optimization of Clone() and
CloneCurrentValue(), so future calls to freeze on the same tree using
different attributes is much faster than the first time. I'll draw up a
ppt when I get the chance so I can show the layout. :)

Sam

-----Original Message-----
From: stringtemplate-interest-bounces at antlr.org
[mailto:stringtemplate-interest-bounces at antlr.org] On Behalf Of Terence
Parr
Sent: Monday, March 30, 2009 4:04 PM
To: stringtemplate-interest at antlr.org Newsletter
Subject: Re: [stringtemplate-interest] StringTemplate Compiler for .NET


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
_______________________________________________
stringtemplate-interest mailing list
stringtemplate-interest at antlr.org
http://www.antlr.org/mailman/listinfo/stringtemplate-interest