[stringtemplate-interest] template expressiveness

[Nate]

Terence Parr wrote:
> On May 11, 2007, at 11:00 AM, Nate wrote:
>   
>>> So you are in favor of allowing randomfunction(randomarg).   
>>> That's  fine.  Plenty of other turing complete template engines if  
>>> you'd  prefer.  Note I've built many sites and I've not had a  
>>> problem.
>>>
>>>       
>> I'm not suggesting calling any function with any argument. I'm  
>> suggesting allowing elements to be picked out of a list by index.
>>     
>
> I'm not sure what value a[i] would be. you cannot change i inside the  
> template.  That means is the same has a fixed named property in an  
> object.  why not use an object instead? a[i] doesn't really buy you  
> anything as far as I can tell.
>
>   
>> Are you even reading my messages? From your lack of capitalization  
>> in most of your responses, I assume you skim through emails and  
>> whip up quick replies.
>>     
>
>   I have extreme tendinitis after 26 years of hacking and I have use  
> voice recognition, which makes things very challenging.
I also suffer from wrist pain, though I can still type on a daily basis. 
I alternate mousing hands and use a Kensington Expert trackball (the 
scroll wheel around the ball is great). I also alternate between the 
trackball and an IR head tracker. You might want to give the head 
tracker a try, it is pretty awesome and priced reasonably ($200) 
compared to other head trackers...
http://www.naturalpoint.com/smartnav/
It requires a small reflective dot to be worn on the foreheard. This 
isn't that big of a deal, except when I forget and go to the grocery 
store with it on. :p I use capslock for clicking, but I've thought about 
getting a pedal switch.

>> I never asked for a turing complete template engine. Apparently, if  
>> someone suggests something you don't understand or don't agree  
>> with, then you tell them they must be using the wrong tool and  
>> should leave? I think I will take your advice. I have found it  
>> difficult to contribute. For example, it took about four emails to  
>> convey how formal argument checking is flawed. Even then, I'm not  
>> sure you actually understand the problem and I am skeptical that it  
>> will be fixed in a future version.
>>     
>
> Given my experience in the area, you should question whether you are  
> describing things clearly or I am not understanding things.
I put extra effort into articulating clearly and I re-read my emails for 
clarity before I send them. Your experience in the area doesn't make up 
for lack of attention. While I'm sure I can be incoherent at times, I 
don't think that is what happend regarding the formal argument checking.

> As you might imagine, I am tired of making the same arguments over  
> and over and over about separation.  Every single engine in the world  
> let you do what you want, and you pick the one that forces separation  
> and then complain about not being able to do what you want.  Why did  
> you pick ST?  Seriously?
>   
Separation is good. Lack of expressiveness is bad. All my complaints are 
centered around expressiveness, not the want to break separation.

>>> Yes, but what about using stuff[i] where i is an attribute (stuff 
>>> [32]  is probably useless)?  In that case you assume is an int.   
>>> What if  you change to a string with a char like '2-321'?
>>>
>>>       
>> stuff[i] gets element at index "i". If "i" is not an integer, an  
>> exception is thrown. Lists can only be indexed by integers, so  
>> where did you get the idea I was asking for randomfunction(randomarg)?
>>     
>
> Because that is the equivalent of calling stuff.index(i)
>   
It is equivalent to calling "((List)stuff).get(i)", which is not at all 
arbitrary.

>>>> No matter how hard you try, you cannot make StringTemplate both   
>>>> useful AND impossible to break separation.
>>>>
>>>>         
>>> Well i've made a few things that are grey area for usability, but   
>>> actually I think I can 'cause I have done useful things w/o  
>>> opening  it up. ;)
>>>
>>>       
>> I can implement Map and invoke random code using an argument passed  
>> in from a template: line 425 of ASTExpr.java, ST v3.0. How much  
>> more open can you get?
>>     
>
> It is all about making things as difficult as possible.  Clearly, as  
> a developer, you could simply alter string template.  I cannot  
> prevent people from circumventing my intentions.  Programmers have  
> ultimate control.
>   
ST allows map access because it allows people to do their work easier. 
Allowing map access allows people to abuse it to break separation, but 
because breaking separation in this way is difficult, ST allows it. We 
seem to be in agreement here. If so, then I'm not sure why we are 
arguing. I am just trying to explore how we can increase expressiveness 
once we conclude that having separation exploits are acceptable as long 
as the exploits are not easily performed.

>>> Really? No problem.  factor into more templates then pass  
>>> arguments.   easy.  just like function calls right?
>>>
>>>       
>> As it is, I am required to have two *completely* separate templates  
>> that are identical, except they output different colored TR tags...
>> $stuff:row1(), row2()$
>>
>> If ST could curry, then it would work...
>> $stuff:row(color="red"), row(color="blue")$
>>     
>
> Ah!  That doesn't work!  crap. added as a bug:
>
> http://www.antlr.org:8888/browse/ST-24
>   
I didn't realize that was supposed to work! I saw your other email that 
it actually does work. This is going to help an enormous amount! I don't 
believe this is documented, though it is not impossible that I missed it.

>> A potentially better solution...
>> $stuff:{
>>    <tr $if(i % 2)$style="color:red"$endif$><td>$it.name$</td></tr>
>> }$
>> Ideally, I should be able to fully manipulate attributes that did  
>> not come from the model.
>>     
>
> Correct. you can do anything you want with an attribute that does not  
> come from the model. That would not break separation per se, although  
> I think he would turn your template into a program, which is also  
> something I don't want.  If order matters, then your template is part  
> of your program.  I don't like side effects. certainly graphics  
> designers do not understand these things, which makes it impossible  
> than for you to have a real designer work on your templates.  I  
> repeatedly asked all the other template designers how they get  
> graphics designers to work with them, because in my experience, there  
> is no way a graphic designer will be able to understand this. state  
> is something they just don't understand.
>   
I can see both sides to having programming in templates. Sometimes state 
is going to be required if you can't change the controller. Maybe state 
could be so restricited that it doesn't affect the entire application 
(eg, only allow local variables in a template's scope). Maybe to balance 
out not having state, some kind of plugin mechanism could be available 
to solve specific template logic problems.

>> Eg, since the int "i" comes from the view, I'd like to be able to  
>> say "if (it % 3 == 1)". If "it" were to come from the model, then  
>> that should be invalid, since that would break separation.
>>     
>
> Yes, but I don't like the idea of side effects at all in the template  
> and as I say I don't like the idea of turning your template into a  
> program. yes, that would be very convenient in some cases.
>
>   
>> Currently ST restricts template logic by applying the same  
>> constraints on template attributes as it does on model attributes.  
>> If the distinction could be made, it could open up an enormous  
>> amount of template expressiveness.
>>     
>
> Yep. can you tell me your thoughts on the fact that now your template  
> expressions would have in order and would become a program? I still  
> think I'm opposed to it because the way you are asking for it means  
> you are in fact adding logic into the template even if the logic is  
> not a function of values in the model.  Imagine making another  
> backend.  Would you not be copying all of that logic multiple times  
> for each target?
>   
The template requires logic at some level. Eg, the ability to loop over 
some values and call other templates is the template logic. The entire 
template logic doesn't have to be copied when making a new skin for a 
site, for example.

I'm not yet sure if what I want is the templates to become a program. 
Without state, problems need to be solved with special handling, such as 
the round-robin template application. When the controller doesn't 
provide the data in quite the needed format for display with ST, there 
seems there is little else to do except refactor the controller.

I wonder if a set of templates could provide a Java layer between the 
controller and the templates. The layer could munge the attributes in 
whatever complex ways the set of templates require. This  seems quite a 
bit less bad than introducing programming inside templates. Maybe it 
could also provide attribute renderers? I have always felt funny writing 
an attribute renderer in Java.

-Nate