[stringtemplate-interest] On Pragmatism Violating Purity For The Win

[Joseph Grace]

*Zenaan Harkness* wrote on *Sun Oct 18 15:39:12 PDT 2009:***



*

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

I don't see "if.true" becoming the default test.  FYI, I see "if"
(i.e., the common already in-use operator) as the default.  That's the
legacy code, so that's the likely default, not some newfangled
operator that is optional.

How about a name change from "if.true" to "native.if"?

By the way, this is just one feature or featureset, e.g., "native.if".
 To me, it's not that complicated, and since it's optional, anyone can
avoid it.  The one or a few tests might not even need tweaking.  That
does not make for a confusing situation to me.  So, I do not see
logistical bugbear here.  I do see potential philosophical issues, but
no logistical nightmare.


>Do we wish to give up deterministic ST output production/ view

>generation so easily?

>I know I don't.

"deterministic ST output":  Are you talking purity or practicality?
Purity prohibits even one operator of native compatibility.  That
would prohibit "native.if"?  Would that one instruction really
contaminate the entire instruction set?  Even if it were totally
isolated to one instruction?  One naming convention?  Well-documented?
 Easy-to-use for those who don't care about other languages?  What if
ST had a flag to warn/error on any use of "native.if"?  That would
solve the problem for portable ST;  just turnon the error flag, and ST
warns/errs on any "native.*" use.  Let the computer flag undesirable
use (or use global search to check).

The rest can use "native.if" with impunity.

> It would mean giving up cross-lang determinism of ST templates.

I do not think so.  Just turn on warnings/errors to prohibit
"native.if", and don't use it.  Those experts writing portable ST
applications would avoid it "like the plague" as I pointed out in my
earlier post.

This linguistic confusion, IMO, is a non-issue.  It's trivially
flagged (naming convention), removed (search-and-replace), and avoided
(just don't use).  I doubt a broader base of ST would involve majority
writing portable ST.  Most just want tools that work on their one
machine.


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

I'm confused.  This whole topic started with the discussion of
splitting "if" into "if" variants.  That's a real world issue from
this list.

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

Umm, I'm assuming this is the proverbial can of worms you are afraid
of?  Is that where all this confusion is coming from?  FYI, I am just
talking about this one feature (or some well-constrained variant), and
I think this feature has merit on its own.  (Let the other issues
stand on their own merits.)

-=-

I'm disappointed this conversation got off track, but then I probably
put too much in one message.  I think the various options I mentioned
raise some interesting potential uses for ST, but they were ideas (and
not concrete).

The basic issues to me at this point are whether a hook should be
added for multiple "if"s?  Whether to include a "native.if"?  Whether
to create an open-ended hook for customization at render time, e.g.,
"native.*"?

Perhaps "native.*" could be the namespace for open-ended render-time
hooks, and "native.if" would default to the native language
conditional and provide a simple example of such customization?

If so, the "native.if" could be there by default, but easily
customized by any programmer.  Frankly, most users (e.g.,
non-programmers) wouldn't care to customize, but necessity is the
mother of invention... so any user that needed/wanted to customize
could use the "native.*" ST operator namespace.  Then perhaps some
language/application specific ST customizations would start appearing!

Cheers,

= Joe =

P.s., no, I do not have any burning use cases for "native.*".  Just
thinking aloud based on the split "if" semantics issue.


*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.antlr.org/pipermail/stringtemplate-interest/attachments/20091018/f9e7f2f2/attachment-0001.html