<span class="Apple-style-span" style="font-family: Times; font-size: medium; "><b>Zenaan Harkness</b> wrote on <i>Sun Oct 18 15:39:12 PDT 2009:</i></span><div><span class="Apple-style-span" style="font-family: Times; font-size: medium; "><i></i><p>
</p><ul></ul></span><font class="Apple-style-span" face="Times"><span class="Apple-style-span" style="font-size: medium;"><i><span class="Apple-style-span" style="font-style: normal; "><pre>>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.
</pre><pre>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.</pre>
<pre>How about a name change from "if.true" to "native.if"?</pre><pre>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.</pre>
<pre><br></pre><pre><span class="Apple-style-span" style="font-family: Times; white-space: normal; "><div><span class="Apple-style-span" style="font-family: monospace; white-space: pre; ">>Do we wish to give up deterministic ST output production/ view</span></div>
</span></pre><pre><span class="Apple-style-span" style="font-family: Times; white-space: normal; "><pre>>generation so easily?
</pre></span>>I know I don't.
</pre><pre>"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).</pre>
<pre>The rest can use "native.if" with impunity.</pre><pre>> It would mean giving up cross-lang determinism of ST templates.</pre><pre><span class="Apple-style-span" style="font-family: Times; white-space: normal; "><pre>
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.</pre>
<pre>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.</pre>
<pre><br></pre><pre><span class="Apple-style-span" style="font-family: Times; white-space: normal; "><pre>> 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.
</pre><pre>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.</pre><div><font class="Apple-style-span" face="monospace"><span class="Apple-style-span" style="white-space: pre;"><span class="Apple-style-span" style="font-family: Times; white-space: normal; "><pre>
> 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.
</pre><pre>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.)</pre>
<pre>-=-</pre><pre>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).</pre>
<pre>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.*"?</pre>
<pre>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?</pre>
<pre>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!</pre>
<pre>Cheers,</pre><pre>= Joe =</pre><pre>P.s., no, I do not have any burning use cases for "native.*". Just thinking aloud based on the split "if" semantics issue.</pre><pre><br></pre></span></span></font></div>
</span></pre></span></pre></span></i></span></font></div>