[stringtemplate-interest] static typing

[Zenaan Harkness]

On Thu, Jun 18, 2009 at 11:29:46AM -0700, Terence Parr 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,

What's the difference between interpreting vs compiling,
and interpreting vs generating proxies?
Both compiling, and generating proxies, appear to me to require a
relatively heavy-weight transformation and subsequent compilation step.

> 
> THIS:
> 
> group T;
> foo(int a, String b) ::= "..."
> 
> BECOMES
> 
> package T;
> class foo extends StringTemplate {
>         public void setA(int a) { setAttribute("a", a); }
>         public void setB(String b) { setAttribute("b", b); }
> }
> 
> Then, you could use it like this:
> 
> T.foo t = new T.foo();
> t.setA(34);
> t.setB("hi");
> 
> Any thoughts? The types would be optional I think.

Here are my questions may help clarify this new feature proposal:

*)
Currently ST uses 'duck typing': in a template, if the attribute I've
just been passed looks like an int, I can use it like an int, and if it
has a quack attribute, I can getQuack with att.quack
See http://en.wikipedia.org/wiki/Duck_typing

I'm having trouble understanding what st static type checking is:

Static typing would give us template-compilation time type checking?
Or intra-template compile time checking?
Intra- template-group template compile time type checking?


*)
Please iterate benefits/ purposes of ST static typing, describing the
problem being solved:


*)
Please iterate contra-indications of ST static typing:


*)
Potential contra-indication:
Cross-language implementation becomes more "icky".
Eg Java "String" and "Map" (ie, Class) types use title case (CamelCase),
but other languages (eg C) prefer all_lower_case.

So perhaps ST uses its own sentence case standard. Let us define that.
Easiest immediate standard for your ST is Java standard since it's
implemented in Java:
I prefer int, string and map over int, String and Map, as the standard,
when writing templates in my template group files.


*)
Please iterate the types. Eg here's a first crack:
   bool

   int
   rational
   real
   complex

   char
   string

   donkey
   alpaca

   list
   map(/ class)
   object (generic type)


*)
If you propose to go "off the beaten track" adding additional types to
the list above, please provide rationale for doing so.


*)
There are two use cases for ST - the purely all-in-st[g]-files use case
(I make heavy use of this (stg files)) and the create templates
programmatically use case (I have only ever used this for testing, but
others on list appear to use heavily).

Does the proposed st static type checking interact differently with
these two use cases?


*)
What about run-time performance impact?


*)
There may be utility in an ST type-contract-enforcement mechanism.

Please keep such mechanism (or the definition of it as per the ST
Standard 1.0) as ST implementation language agnostic as possible.
I use Java pretty much exclusively at the moment, yet I have a strong
desire for the cross language neutrality of ST to be maximised.
Maximises both our community, and cross-language applicability of
templates, examples, documentation, etc.  Technical leverage.


*)
Speaking of standards:
The contract of ST is a "standard" which contract must be met by
implementers of that standard, such as Java ST, C# ST, etc.

Ideally ST is defined in a standard document, independent of any
implementation, which standard is versioned, such as ST 1.0, ST 1.1, ST
2.0 etc.

If we had an ST standard document which we could refer to, it would help
us to think about changes proposed, impact on various implementers, etc.


Got me inspired again ... what _is_ it with ST?

I know, it's giving my favourite imperative language some of the
benefits of a Lisp machine. Really gotta learn that lisp one day...


Regards
Zenaan

-- 
Homepage: www.SoulSound.net -- Free Australia: www.UPMART.org
Please respect the confidentiality of this email as sensibly warranted.