[Arjen Markus] (21 december 2005) Spreadsheets differ in the way they perform their computation from ordinary programs (in Tcl or Fortran or most other languages): you do not need to specifiy the ''order'' 
of the computations. Somehow they determine that themselves: you can refer to cell Z100 in the formula for cell A1, for instance.

Can we do the same? Yes, we can.

It is even possible without analysing the formulae for references to other variables. 

The script below defines a simple set of computations, one for each variable. 
Then it prints the variable "volume" - without it having been set before....

Run it and you will see what happens!

We need a buzzword for this paradigm, so that is why I called the page '''Demand-driven computation''' 
or '''DDC'''. (But seriously, you could do interesting things this way)

----

 # demand.tcl --
 #     "Demand-driven" computation
 #
 namespace eval ::DemandDriven {
 }

 # compute --
 #     Register the variables and the associated computations
 # Arguments:
 #     list         List of variable-expression pairs
 # Result:
 #     None
 # Side effects:
 #     The variables are defined in global namespace and
 #     there are read traces attached to them
 #
 proc ::DemandDriven::compute {list} {

     foreach {v expr} $list {
         global $v
         trace add variable ::$v read [list ::DemandDriven::GetValue $expr]
     }
 }

 # GetValue --
 #     Get the value of the variable
 # Arguments:
 #     expr         The expression by which to get the value
 #     name         Name of the variable (it is global!)
 #     dummy        Dummy in this context
 #     op           Operation (dummy too)
 # Result:
 #     None
 # Side effects:
 #     The variable is set
 #
 proc ::DemandDriven::GetValue {expr name dummy op} {
     #
     # We need to take more care: traces are not nested ...
     if { ! [info exists ::$name] } {
         set count 0
         while { [catch {
                  uplevel #0 [string map [list NAME $name EXPR $expr] {set ::NAME [expr {EXPR}]}]
              } msg] } {
             if { [regexp {can't read \"(.*)\": no} $msg ==> varname] } {
                 uplevel #0 [list set ::$varname \
                     "\[::DemandDriven::GetValue [list [lindex [trace info variable ::$varname] 0 1]] $varname {} read\]"]
                 incr count
             } else {
                 puts $errorInfo
                 break
             }
             if { $count > 3 } { break }
         }
     }
 }

 # ask --
 #     Print a question and ask for the answer
 # Arguments:
 #     question     The question to be posed
 # Result:
 #     Whatever the user types
 #
 proc ask {question} {
     puts -nonewline $question
     flush stdout
     gets stdin
 }

 # main --
 #     Test this idea
 #
 ::DemandDriven::compute {
    volume       {$sphere? $volumeSphere : $volumeCube}
    sphere       {[ask "Is it a sphere (1) or a cube (0)? "]}
    volumeSphere {4.0*$pi/3.0*pow($rad,3)}
    volumeCube   {pow($side,3)}
    pi           3.1415926
    side         {[ask "The side of the cube: "]}
    rad          {[ask "The radius of the sphere: "]}
 }
 puts "Compute the volume of a sphere or cube:"
 puts "Volume: $volume"
----
[NEM]: Very nice! [Mozart]/Oz has the concept of a ''dataflow variable'' which is
essentially very similar to this. A dataflow variable is like a logic variable in [Prolog]
in that it is initially unbound and once given a value it keeps it (i.e., it is not mutable). 
However, dataflow variables are also used as a communication/condition synchronisation mechanism 
between [threads]: if one thread tries to get the value of an unbound variable 
it will suspend until another thread binds the variable (through [unification]). 
This allows for [declarative programming] of concurrency (see [Concurrency concepts]), 
and is really a very interesting technique as it really takes a lot of the complexity 
out of multi-threaded programming. 
The [BOOK Concepts, Techniques, and Models of Computer Programming] has much more on the subject.

[HJG] I get 'Error: can't read "volume": can't read "errorInfo": no such variable'.
Maybe this uses a Tcl 8.5 feature ?

[AM] That is strange ... I use a Tcl 8.4 feature ([lindex] with two indices) but that is all. Are you using ''[tclsh]'' ? [Wish] on [Windows] will have a severe problem - [[gets]] is not working from a [console]. ''[RS]: Have a look at the [gets workaround] :)''

In a wish console on Windows I get:
% source demand.tcl
Is it a sphere (1) or a cube (0)? can't read "volume": can't read "errorInfo": no such variable
(tmp) 2 % 

This brings to [CL]'s mind, along with dataflow variables, inferencing in
[expert system]s, generally under the rubric of "forward [[or backward]] chaining".

----
[[
[Category Concept]
]]