[antlr-interest] ST 4.0 planning

[Loring Craymer]

Ter--

I think that the reflection requirement is unnecessary and undesireable.  An attribute is usually one of:  1.) a String, 2.) a StringTemplate, or 3.) Boolean, and you could probably avoid Booleans as well with a bit of judicious design (single-valued "true" or "false" strings, for example).  On rare occasion, it may make sense to support an esoteric data type, but that can be handled via wrapper:  the wrapper, after all, only needs to know how to do "toString()", and it is trivial to implement subclass wrappers for each esoteric type.  For that matter, you could support a generic Java wrapper that used reflection, but subclass a base wrapper class in languages that do not support reflection.

--Loring

> From: Terence Parr <parrt at cs.usfca.edu>
> To: stringtemplate-interest <stringtemplate-interest at antlr.org>
> Cc: antlr Interest <antlr-interest at antlr.org>
> Sent: Monday, September 8, 2008 10:48:19 AM
> Subject: [antlr-interest] ST 4.0 planning
> 
> Dear ST-o-philes and related humans,
> 
> I am starting the planning stages for ST 4.0. I begin my sabbatical  
> next May, a few months after I finish this current book. I plan on  
> writing software like crazy (for 15 months!). This will include  
> optimizing ANTLR and hopefully converting ANTLR and ST to be ANTLR v3  
> clean; no more ANTLR v2 requirement.
> 
> As part of converting ST to v3 grammars, I took a look at updating  
> things.  As I looked through all the complicated code that manages  
> dynamic scopes, parameters, and nested templates I realized that there  
> is a lot of stuff going on in there.  ST groove organically from a  
> simple string with holes in it to a sophisticated tree-based  
> interpreter. Tree-based Interpreters are much more difficult to build  
> then, say, a byte code interpreter. Further, debugging ST stuff is  
> quite difficult because all you have are objects and you have to chase  
> a lot of pointers through hash tables and so on to figure out what is  
> going on.  There is no code to step through related to your templates.
> 
> I am contemplating moving to a JSP-like model where I generate Java  
> (or C# or Python, ...) instead of doing an interpreter. There are a  
> number of advantages:
> 
> 1. In principle, we could use the rechargeable architecture pattern of  
> ANTLR to generate whatever source code we want; C++ and so on. the  
> only requirement would be some sort of reflection still because I  
> don't want attributes to be typed in ST. That means that you'd need  
> RTTI for C++, which it supposedly has now.
> 
> 2.  I would suspect that the templates would go much faster when  
> executing "natively" in Java.
> 
> 3. You could debug templates by stepping through them just like you do  
> ANTLR parsers. Templates would translate to Java methods. Groups would  
> translate to objects.  Like JSP, we could automatically compile things  
> in the background. This means that they would go slow the first time  
> you ran the template. Also, I would have to investigate a custom class  
> loader so that I could unload templates.
> 
> I'm planning on breaking with absolute backward compatibility to fix a  
> number of design flaws that came about because requirements changed  
> during the last eight years.
> 
> So, it is a bit premature, but I like to have things to think about  
> while I'm waiting in line etc...
> 
> The idea of generating Java code is growing on me. Note that it would  
> only be generating Java or stay an interpreter. I would not do both.  
> Those are two totally separate products almost in terms of  
> implementation.
> 
> Ter
> 
> List: http://www.antlr.org/mailman/listinfo/antlr-interest
> Unsubscribe: 
> http://www.antlr.org/mailman/options/antlr-interest/your-email-address