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

[Zenaan Harkness]

On Sun, Oct 18, 2009 at 05:59:07PM -0700, Joseph Grace wrote:
> *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"?

native.* seems clear enough.

That could be suitable. I'd still like to see an actual use-case-
with-code that requires this though.

...
> Purity prohibits even one operator of native compatibility.  That

If we added native.if, are there other operators you see
being useful in the native.* library?


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

Modifying ST into 'platform specific' variants is a significant
change if it were undertaken.

An actual example would be useful to the discussion.

I'm thinking that an actual example, which clearly identifies
the problem from a specific language (eg python, C#, whatever)
might be easy to counter with existing simple ST techniques.

If native.if were the only elegant solution, then that would be
useful information to the discussion ...


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

It may have merit enough to stand on its own.

A native.* library would be good to think/ plan for in advance
though, rather than one feature at a time, don't you think?

Good discussion
zen

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