[prev in list] [next in list] [prev in thread] [next in thread] 

List:       stringtemplate-interest
Subject:    Re: [stringtemplate-interest] static typing
From:       Zenaan Harkness <zen () freedbms ! net>
Date:       2009-06-20 3:11:10
Message-ID: 20090620031110.GA15153 () freedbms ! net
[Download RAW message or body]

On Fri, Jun 19, 2009 at 12:11:26PM -0700, Terence Parr wrote:
> On Jun 18, 2009, at 6:51 PM, Bill Venners wrote:
> 
> > 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  

Getting better errors for us mere mortal ST programmer users is a prime
consideration. How best to achieve that is first and foremost a language
(ST) standards question, and secondarily an implementation question.

If nice errors (and warnings!) can be got without any standards change,
all the better.

Name checking, with ST compile time options for warnings or errors to
choose desired behaviour, would be really good; oh to get clean line
numbers and warnings...


> 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.

Yes, it must be an option to cause this to be a feature, a warning, or
an error. Bonus points for line numbers.


> 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.

No disagreement on this one :)


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

ST interpreter/ compiler speed is important for those using it in
an online (sometimes called soft real time) mode.

I use ST currently in an offline mode - pre-generating my outputs based
on my ST templates. But I can clearly see how my work could apply in an
online setting. So performance, in the "real" world, is never far from
the top of my list of considerations :)


> > 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.

Yes please!

> > 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  

Not sure I understand this, at least in context of stg files.


> check for misnamed attributes. I'm beginning to think it's not worth  
> it, though. For code generation like ANTLR stuff, generating code  

Of course, nice errors or warnings (optional) to say eg:
WARNING: st/yourgroup.stg:63: att.quack not found, using NULL instead.

would be really good. But again, implementation detail, that's all...


> would be fine. For websites, generating code won't work because of all  
> the classes you generate.
> 
> Ter
> _______________________________________________
> stringtemplate-interest mailing list
> stringtemplate-interest@antlr.org
> http://www.antlr.org/mailman/listinfo/stringtemplate-interest

-- 
Homepage: www.SoulSound.net -- Free Australia: www.UPMART.org
Please respect the confidentiality of this email as sensibly warranted.
_______________________________________________
stringtemplate-interest mailing list
stringtemplate-interest@antlr.org
http://www.antlr.org/mailman/listinfo/stringtemplate-interest
[prev in list] [next in list] [prev in thread] [next in thread]