[stringtemplate-interest] StringTemplate extensions

[Terence Parr]

On Jan 4, 2006, at 2:53 AM, Mark Venbrux wrote:
> Hi,
> I'm pleased to have found AntLR and StringTemplate and I've used it
> for about a month now. Its powerful and fun at the same time!

Hooray!

> But.....(probably this issue was raised several times already)
> Sometimes I think that XSL for output generation could be more
> effective. I seems that one StringTemplate outputmodel will not hold
> for the compilation of a 'C' like language to multiple target assembly
> languages.

It should be ok.  ANTLR v3 currently generates multiple target  
languages and I even had bytecode generation in there for DFAs at one  
point...all without modifying the code generator logic, just  
templates. :)

> Currently I think that the approach of choice would be to have
> different tree parsers that create output models targeted a the
> different output languages. Am I right? In my interpretation it means
> that tree parsing occurs somewhere in a grey area between Model and
> View. Please comment on this.

Good question.  My belief is this:

AST: model
Tree parser: controller
templates: view

So to get multiple targets you need at least multiple views, with  
hopefully one model/controller.

> Anyway, currently only one outputmodel is sufficient for me. I have
> added some options to StringTemplate though:
>
> In: ....\stringtemplate-2.2\src\org\antlr\stringtemplate\language 
> \action.g
>
> optionList! returns [Map opts=new HashMap()]
>    :   "separator" ASSIGN e:expr {opts.put("separator",#e);}
>    |   "order" ASSIGN e2:expr {opts.put("order",#e2);}// could be:
> "reverse" or sort...
>    |   "repeat" ASSIGN e3:expr {opts.put("repeat",#e3);}// could  
> be: "10"
>    ;

Interesting...could be useful.  I'm not opposed, but can anybody else  
comment on the need? They certainly don't break the "rules".

> I've updated
> ...\stringtemplate-2.2\src\org\antlr\stringtemplate\language 
> \ASTExpr.java
> accordingly. Probably not the best implementation, but it works for  
> me.

I'm sure it's great :)

> The reverse option is used for pushing parameters on the stack, the
> repeat option for default initializers of arrays.

Excellent use-cases!

> Two questions:
> - Is this the right way to go?

I'm thinking that perhaps a more functional approach is what we want  
for the order:

<args:{a|<a.type> <a.name>;}>

does them in order and to reverse, perhaps

<args:reverse():{a|<a.type> <a.name>;}>

or to be consistent with first(), rest() built-in functions,

<reverse(arg):{a|<a.type> <a.name>;}>

This one makes sense, right?

As for repeat, seems an option is the best

<"0"; repeat="20">

or

<initvalue; repeat="20">

Hmm...I'm uncomfortable with the notation a bit, but separator and  
repeat seem similar enough to warrant another option.  Actually, you  
are probably asking for this:

<initvalue; repeat="<n>">

or is it

<initvalue; repeat=n>

where n is an attribute saying how many times to do something.   
Hmm...now my model-view separation alarm is going off.  Hmm...

> - If so, is it possible to have these options integrated in  
> StringTemplate?
>
> Cheers, and thanks for the splendid work,

Thank you for your suggestions!

Ter