Posted to tcl by colin at Wed Apr 20 02:48:40 GMT 2016view pretty

There's a lurking confusion due to nomenclature.

In Tcl, a variable may be undefined, but a value may never be undefined.  The 'value of a variable' is often shortened to 'a value', as in the sentence "the value of x is undefined" as meaning "the variable x is undefined" and "x has no value."

In L, it seems, there is a distinguished quality or property associated with every value.  It is currently called "undefined/defined", and it may be interrogated.  To avoid the confusion, one might call it "red/blue" instead.

What "red/blue" really means (in L, as I understand it) is that the value under inspection derives via an uninterrupted chain of computation from some function which returned red or blue, where an "interruption" is a function which changes the value of red/blue.

ISTR some javascript implementations have or had a similar property which was set on every string derived from user input (input from a web form.)  Such strings were considered 'tainted', and the taint persisted alongside the value, only being removed as a result of some considered action on the part of the program.

I can understand the utility of 'tainted/untainted' in the javascript context, although it is a lot of effort to implement in an attempt to impose discipline on programmers.

L's red/blue differs from js's tainted/untainted in that all 'red' values are equivalent in L, whereas 'blue' values may be distinct.  Javascript 'tainted' values may be distinct from one another.

The fundamental distinction between an L value and a Tcl value is type.  L distinguishes between a value whose visual representation is 1.23 which derived from an operation/function yielding 'numeric' types, and a value whose visual representation is 1.23 which derived from an operation/function yielding 'string' types.

Tcl does not distinguish between [expr {1.23 + 0.0}] and "1.23", L presumably  (therefore) must *explicitly* coerce the results of calling any Tcl function to a type other than 'string', where L considers there to be a significant difference.  A bit like how you need a dope vector to generate json from tcl.

Because L requires the red/blue property to be preserved on any value returned from a tcl call which was passed a red value, and because it's impossible to construct a dope vector for every such case, L coopts a kinda-spare bit to store red/blue and relies upon Tcl's implementation to leave it unmolested  (which it will do, usually.)

The problem being solved for L is *not* the existence of 'undefined' values.  Such could be implemented in L as a distinct type.  The problem being solved is that L has to interface with a type-free language in such a way as to preserve type between calls.  I wonder, incidentally, whether numeric NaN handling in Tcl could not have been tricked up to satisfy this need, but that's a moot conjecture.

Comments

Posted by dbohdan at Wed Apr 20 18:31:35 GMT 2016 [text] [code]

The text above looks bad. Perhaps it will be more readable in a comment. ----- There's a lurking confusion due to nomenclature. In Tcl, a variable may be undefined, but a value may never be undefined. The 'value of a variable' is often shortened to 'a value', as in the sentence "the value of x is undefined" as meaning "the variable x is undefined" and "x has no value." In L, it seems, there is a distinguished quality or property associated with every value. It is currently called "undefined/defined", and it may be interrogated. To avoid the confusion, one might call it "red/blue" instead. What "red/blue" really means (in L, as I understand it) is that the value under inspection derives via an uninterrupted chain of computation from some function which returned red or blue, where an "interruption" is a function which changes the value of red/blue. ISTR some javascript implementations have or had a similar property which was set on every string derived from user input (input from a web form.) Such strings were considered 'tainted', and the taint persisted alongside the value, only being removed as a result of some considered action on the part of the program. I can understand the utility of 'tainted/untainted' in the javascript context, although it is a lot of effort to implement in an attempt to impose discipline on programmers. L's red/blue differs from js's tainted/untainted in that all 'red' values are equivalent in L, whereas 'blue' values may be distinct. Javascript 'tainted' values may be distinct from one another. The fundamental distinction between an L value and a Tcl value is type. L distinguishes between a value whose visual representation is 1.23 which derived from an operation/function yielding 'numeric' types, and a value whose visual representation is 1.23 which derived from an operation/function yielding 'string' types. Tcl does not distinguish between [expr {1.23 + 0.0}] and "1.23", L presumably (therefore) must *explicitly* coerce the results of calling any Tcl function to a type other than 'string', where L considers there to be a significant difference. A bit like how you need a dope vector to generate json from tcl. Because L requires the red/blue property to be preserved on any value returned from a tcl call which was passed a red value, and because it's impossible to construct a dope vector for every such case, L coopts a kinda-spare bit to store red/blue and relies upon Tcl's implementation to leave it unmolested (which it will do, usually.) The problem being solved for L is *not* the existence of 'undefined' values. Such could be implemented in L as a distinct type. The problem being solved is that L has to interface with a type-free language in such a way as to preserve type between calls. I wonder, incidentally, whether numeric NaN handling in Tcl could not have been tricked up to satisfy this need, but that's a moot conjecture. }

Posted by dbohdan at Wed Apr 20 18:32:55 GMT 2016 [text] [code]

Okay, it isn't. :-) Just read it at https://sourceforge.net/p/tcl/mailman/message/35026342/.