[stringtemplate-interest] static typing

[Terence Parr]

On Jun 18, 2009, at 6:51 PM, Bill Venners wrote:

> Hi Terrence,
>
> On Thu, Jun 18, 2009 at 11:29 AM, Terence Parr <parrt at cs.usfca.edu>  
> wrote:
>>
>> Howdy. One of the things I would like to consider for the next  
>> version
>> of ST is static type checking. Easy way to do that is to generate  
>> Java
>> code from the templates and then let the compiler figure it out. If I
>> want to keep the system interpreted, though, we need to be more
>> clever. We could keep the interpreted nature but generate some  
>> proxies
>> that provided setter methods. For example,
>
> Static typing? Blasphemy!

Yeah, I know. in my paper, I suggested that type information was an  
entanglement with a model, which is. However, we actually have to know  
the type we are using properties of an incoming object. to be  
completely disentangle, we need to restrict our session to the Object  
interface (i.e., it can answer toString()). In practice, $user.name$  
is required. We don't explicitly say the type, but that doesn't mean  
that user doesn't have to satisfy a certain interface.

I just had a conversation with Tom Burns, the coinventor of ST. He  
pointed out that, while it sometimes bites you, getting the name wrong  
and the type wrong is not a huge stumbling block. In fact, he points  
out that sometimes he relies on inexact type. So, $user.name$ should  
work in most cases, but if he passes in something without a name  
property, it just evaluates to null. He relies on that for flexibility.

He also indicated that he has perhaps 40,000 templates ( multilingual  
stuff). creating 40,000 classes to get static typing is not a good  
trade.

He things that ST could be faster, but he just throws hardware the  
problem for now.

> Actually, I must say that one problem I've had with ST is that I have
> on occasion deployed bugs that were simply typos. I like being able to
> run in interpreted mode for quick deployment, but frankly wanted some
> kind of name checking that was automated.

Yeah, that's my motivation: I want to use the compiler to check for  
problems with names and also with types. after talking to calm this  
morning however, I'm not sure the trade-off is worth it. probably we  
could do some "coverage" type stuff to help us check things at runtime.

> Still don't have it. Type
> checking would do it, but in thinking about it a long time ago, I
> thought there were some dynamic things you do in ST that wouldn't be
> possible with a static approach.

Yeah, the static thing really screw stuff up. on the other hand, it  
makes a C. and C++ targets impossible in interpreted mode. we could  
generate code that implemented a subset, though.

> I can't remember exactly what I was
> thinking of, but something like selecting a template based on an
> attribute passed in, then using that template? Not sure.

Yep, you are right.

> So I'm curious, 1) is there any dynamic feature of ST you can think of
> that would not work with a static approach?

yep.

> And 2), what made you want
> to add static typing?

I can help it; I like type information for maintenance and I want to  
check for misnamed attributes. I'm beginning to think it's not worth  
it, though. For code generation like ANTLR stuff, generating code  
would be fine. For websites, generating code won't work because of all  
the classes you generate.

Ter