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

  1. There's a lurking confusion due to nomenclature.
  2.  
  3. 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."
  4.  
  5. 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.
  6.  
  7. 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.
  8.  
  9. 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.
  10.  
  11. 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.
  12.  
  13. 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.
  14.  
  15. 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.
  16.  
  17. 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.
  18.  
  19. 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.)
  20.  
  21. 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/.