[stringtemplate-interest] On Pragmatism Violating Purity For The Win (was: ST interface: canonical name, and null vs missing vs empty vs nonexistent)

[Zenaan Harkness]

On Sun, Oct 18, 2009 at 08:39:20AM -0700, Joseph Grace wrote:
> *Zenaan Harkness* wrote at *Sat Oct 17 19:16:09 PDT 2009:**
> >> NB: "if.true" (boolean) is defined relative to the host language (not to>> ST), which can vary in meaning w/r/t whether "" is false or not in the host>> language. So the host language (I would say) should be the determining>> factor of the "native" semantics for boolean in ST for ease of use with each>> and every host language. In other words, ST adopts the host language T/F>> semantics for native least astonishment, and ease of use.>
> >That's good for the newcomer, but not so good for the system and library
> >builders.
> >
> >Java's awt lib illustrates my point, where 'pixel perfect' layouts [...]
> 
> I agree with your concern in general but not in this case so much.
> 
> Yes, this feature would be more for language impedance matching, and
> not so much for large system building.  As a complement to the system
> building approach, "if.true" would provide a language-relative
> solution to boolean, to perfectly match the host language's
> interpretation of TRUE/FALSE.

I see. Language impedence matching. Could be useful.

I guess my concern is that if such a feature were in ST, that it not be
so simple to type that people would use it as the default true/false
test.

If it is a feature specifically for impedence matching, then it would
have relatively limited 'real world necessity' usage scope, say in
cross-language conversion templates or some such.

And the reason I say this is that if it becomes the 'default usage' (eg.
in tutorials/ on this list/ or just because it's so easy to type) then
the templates created with this feature will be non-deterministic across
ST runtimes/ languages/ implementations.

Do we wish to give up deterministic ST output production/ view
generation so easily?

I know I don't.

(Yes I realise it would be deterministic within the particular ST
runtime targetted, but then we would want to somehow declare that
assertion, and then add an option to ST to balk on failed assertions,
etc - the complexity is rising here, for such a feature.)

Adding a personal viewpoint - my feeling from using ST for a few years
on relatively small personal projects (although with some intensity), is
that I have had to get clear on ST boolean semantics, and that this is
par for the course. Each language, and ST is a language, has its
idiosyncracies. List processing. Boolean logic.  Predicates.
Documentation/ comments. Inheritance. Librarization/ componentization/
grouping. Facilities for complexity management.  Calling conventions
(eg, one fn to another, or in ST - one template to another).

There are so many places here where a language disconnect occurs, or
even simply just that the subtleties need to be known, that the
advantage of adding a host-env/lang-specific version of one ST feature
would, I feel confident, be outweighed by the increased overhead of
having to think about "which" features have a host-implementation
impedence matched version, and having to remember which version is that
version, and which version is the ST 'native' version. I think it's
better to keep ST 'primary usage' cleaner, and, if really needed,
provide impedence matching functionality either in libraries, or at
least as non-default behaviour/ clearly-identified-as-non-standard
syntax.


> System builders could avoid it like the
> plague (as its optional), but it could still cover the bases for
> others.  Since it's just one feature with many if.* duplicates, I
> don't think the AWT example applies in this case (though it would in
> more complex cases).  There's no necessity to use "if.true", and it's
> not intertwined with a bunch of other features.  "if.true" would be
> independent and optional, just one isolated feature.  System builders
> would be unaffected by this feature unless they choose to use it.
> 
> I prefer to think of "if.true" as getting the best of both worlds:
> absolute definitions (predefined, for robust systems) and relative
> (impedance matched to the host language, for lightweight, seamless
> solutions).  In some (many?) cases, if.true would duplicate one of the
> other if.*, so it may only provide duplicate functionality in some
> languages, but it would often be welcome where it does provide
> specific semantics for its seamless use and transparent debugging.
> And it would always respect the host language interpretation of
> TRUE/FALSE, so that TRUE in the language would always be TRUE in the
> StringTemplate (fewer surprises, lower learning curve, less debugging,
> reliable and unambiguous host language programming).

At this point, I do feel that we would need to see some real examples,
to be able to make a fair decision on such a feature being needed.
'If it aint broke, don't fix it.'

I only work in one host language, Java, so I'll have to leave such
examples up to you or others.


> >Regarding per-host-language "customizations" however, unless presented
> >with an example for which we cannot resolve or otherwise handle
> >'comfortably' and 'easily' using 'strictly-standard' ST semantics/
> >syntax, then let's stick to the high ground as long as possible.
> 
> For the sake of discussion... taking the low-ground! :-)
> 
> I see three questions with the if.* syntax and hook(s):
> 
> 1. grammar: would "if.*" syntax and customizability be a reasonable
> evolution for the StringTemplate language?

It would mean giving up cross-lang determinism of ST templates.
Which doesn't feel like a good thing to me.


> Since noone's complaining (yet?), I am supposing "if.*" is viable
> grammar-wise.

I don't see why not.


> 2. philosophy: would Ter be OK with it? Is opening Pandora's Box in a very
> focused way acceptable (even though it could be abused to Turing
> Completion)? StringTemplate is his baby, and he might have to rewrite _all_
> his papers on StringTemplate! ;-) Seriously, the Pandora's Box nature of the
> hook puts a twist on the language and its use. It may open many doors, but
> it Ter needs to be happy with the approach going forward.
> 
> Only Ter knows for sure. IMO, it could provide an elegant solution to making
> StringTemplate flexible but doing so in a way that is very explicitly for a
> specific, well-defined, limited use: Gentleman's Agreement if you will. Even
> though it could be abused, it wouldn't be the language's or language
> designer's fault. Also, abuses would be obvious just by looking at the
> if.hook implementation by any StringTemplate coder. Use at your own risk, as
> the saying goes.

Need a concrete example of a problem it solves. Hasn't been an issue on
the lists before know, and this discussion so far we've had the luxury
of living in hypothetical land.


> 3. Pragmatism & Purity: does this feature buy StringTemplate any new value
> or use cases (or potentially expand the user base :-)?
> 
> A. The first use case I have in mind is the "escape valve" use case. I know
> in corporate programming (I've been in this situation myself, and I'm sure
> many of you have as well), a programmer may _know_ something will work
> exceptionally well, but it's NIH (Not Invented Here). The manager and/or
> project leads are all very (and when I say "very", I mean pathologically)
> averse to change, risk, the unknown --- especially anything which may lead
> down a proverbial rabbit hole with nothing to show for it but lost schedule.
> They neither listen nor trust, and come up with _any_ excuse to shoot stuff
> down. The escape valve preempts their "rabbit hole" attacks with an
> all-encompassing "Not a problem. Pragmatism Prevails. In worst case, we'll
> just 'if.*' our way to a solution (and out of any rabbit hole, real or
> imagined)!"

It's that "or imagined" bit. We are just dealing with straw-men, until
there's a concrete problem demonstrated, which we can't readily solve
otherwise.

> StringTemplate's strength, purity & strict separation of concerns, could be
> perceived as one such rabbit hole.
> 
> To get in the door, it's hard enough, but as a programmer in a "rabbit hole"
> catch-22, I could always use the "escape valve" of the external "if.*" hook

Again, there are more areas in st, where host-env specific stuff could
be applied. No point adding just one without also addressing the others.

...
> "if.*" anyone?

NACK, to host-lang-specific version, at this point, for me.


> C. Hmm, just occurs to me (again, not sure of use case, but here goes), the
> if.hook would allow for render time computation (instead of the usual load
> time computation via t.add(...)). This could be useful for touchy debugging
> (e.g., print the time when the render happened, to coordinate with other
> aspects of the system or see any hangups in the rendering). It could also
> dovetail better with some render-time only systems, making StringTemplate a
> possibility where it never was before. Compute on demand >> compute
> everything up-front.
> 
> "render.*" anyone?

I believe Ter has on the agenda, better debugging, such as line-number
outputs etc.

Also, we of course already have custom attribute renderers...


> D. Going further with render.*, "stream.*" could also cut down on
... 
> "if.stream" anyone?

Stream processing I think is a different kettle of fish.
Perhaps awk and sed?

No-one's presented the list with an actual use-case...


cheers
zen

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