Documented indirect variable addressing.

Fork: 0

tundra / tconfpy

Browse code Documented indirect variable addressing. master
1 parent 3d5d1ca commit 82f3b45ed320b6df765537e902039151a0395c1e tundra authored on 8 Apr 2004

Patch

Unified Split

Showing 1 changed file

                Ignore Space
               Show notes
              View
            
          
          110 ■■■■■
          tconfpy.3
 exception to this is if an attempt is made to refer to an
undefined/non-existent variable.  This generates an error.
 
.IP \(bu 4
Unless a variable as been marked as "Read Only" by the program,
you can continue to change its value as you go.  Simply adding
another line at the end of our example above will change the value
of \'Greeting\' to something new:
 
.nf
    Greeting = Generic Greeting Message
.fi
 
In other words, the last assignment statement for a given variable
"wins".  This may seem sort of pointless, but it actually has great
utility.  You can use the \'.include\' directive to get, say, a
"standard" configuration provided by the system administrator for a
particular application.  You can then selectively override the
variables you want to change in your own configuration file.
 
.IP \(bu 4
The variable \'Greeting\' now contains the
.B string
"Hello Mr. Tconfpy, you look great for someone 101!"   This is true even
if variable \'MYAGE\' has been defined by the calling program to be
.B strings
regardless of the actual type of the variables involved.
 
 
.IP \(bu 4
Unless a variable as been marked as "Read Only" by the application
program, you can continue to change its value as you go.  Simply
adding another line at the end of our example above will change the
value of \'Greeting\' to something new:
 
.nf
    Greeting = Generic Greeting Message
.fi
 
In other words, the last assignment statement for a given variable
"wins".  This may seem sort of pointless, but it actually has great
utility.  You can use the \'.include\' directive to get, say, a
"standard" configuration provided by the system administrator for a
particular application.  You can then selectively override the
variables you want to change in your own configuration file.
 
.SS Indirect Variable Assignment
 
The dereferencing of a variable's value can take place on either
the right- or
.B left-hand-side
of an assignment statement.  This means so-called "indirect"
variable assignments are permitted:
 
.nf
     CurrentTask    = HouseCleaning
     [CurrentTask]  = Dad
.fi
 
To understand what this does you need to realize that before
\*(TC does anything with a statement in a configuration file, it
replaces every variable reference with its associated value
(or produces an error for references to non-existent variables).
So the second statement above is first converted to:
 
.nf
    HouseCleaning = Dad
.fi
 
i.e., The value \'Dad\' is assigned to a (new) variable called
\'HouseCleaning\'.  In other words, putting a variable reference
on the left-hand-side of an assignment like this allows you
to access another variable which is named "indirectly".  You have
to be careful when doing this, though.  Consider a similar, but
slightly different example:
 
.nf
     CurrentTask    = House Cleaning   # This is fine
     [CurrentTask]  = Dad              # Bad!
.fi
 
The reason this no longer works is that the indirect
reference causes the second line to parse to:
 
.nf
    House Cleaning = Dad
.fi
 
This is illegal because whitespace is not permitted in variable names.
\*(TC will produce an error if it sees such a construct.
 
If you get into the habit of reading \'[something]\' as,
"The current value of \'something\'" this whole area of variable
naming and referencing will be easier to keep clear in your
thinking.  See if you understand what the following does
(if you don't, try it out with \'test-tc.py\'):
 
.nf
    foo   = 1  
    bar   = 2
    [foo] = bar
    [bar] = [foo]
.fi
 
You can get pretty creative with this since variable references
can occur pretty much anywhere in an assignment statement.
The only place they cannot appear is
.B within
another variable reference.  That is, you cannot "nest" references:
 
.nf
    # The Following Is Fine
 
    FOO          = Goodness
    BAR          = Me
    Oh[FOO][BAR] = Goodness Gracious Me!
 
    # But This Does NOT Do What You Might Think
 
    [FOO[BAR]] = Something Or Other  # Avoid nested constructs like this!
.fi
 
.SS Lexical Namespaces
 
The discussion of variable assignment and reference needs to be
expanded now to include the idea of "lexical namespaces".  Think of a
 exception to this is if an attempt is made to refer to an
 undefined/non-existent variable.  This generates an error.
 .IP \(bu 4
-Unless a variable as been marked as "Read Only" by the program,
-you can continue to change its value as you go.  Simply adding
-another line at the end of our example above will change the value
-of \'Greeting\' to something new:
-.nf
-    Greeting = Generic Greeting Message
-.fi
-In other words, the last assignment statement for a given variable
-"wins".  This may seem sort of pointless, but it actually has great
-utility.  You can use the \'.include\' directive to get, say, a
-"standard" configuration provided by the system administrator for a
-particular application.  You can then selectively override the
-variables you want to change in your own configuration file.
-.IP \(bu 4
 The variable \'Greeting\' now contains the
 .B string
 "Hello Mr. Tconfpy, you look great for someone 101!"   This is true even
 if variable \'MYAGE\' has been defined by the calling program to be
 .B strings
 regardless of the actual type of the variables involved.
+.IP \(bu 4
+Unless a variable as been marked as "Read Only" by the application
+program, you can continue to change its value as you go.  Simply
+adding another line at the end of our example above will change the
+value of \'Greeting\' to something new:
+.nf
+    Greeting = Generic Greeting Message
+.fi
+In other words, the last assignment statement for a given variable
+"wins".  This may seem sort of pointless, but it actually has great
+utility.  You can use the \'.include\' directive to get, say, a
+"standard" configuration provided by the system administrator for a
+particular application.  You can then selectively override the
+variables you want to change in your own configuration file.
+.SS Indirect Variable Assignment
+The dereferencing of a variable's value can take place on either
+the right- or
+.B left-hand-side
+of an assignment statement.  This means so-called "indirect"
+variable assignments are permitted:
+.nf
+     CurrentTask    = HouseCleaning
+     [CurrentTask]  = Dad
+.fi
+To understand what this does you need to realize that before
+\*(TC does anything with a statement in a configuration file, it
+replaces every variable reference with its associated value
+(or produces an error for references to non-existent variables).
+So the second statement above is first converted to:
+.nf
+    HouseCleaning = Dad
+.fi
+i.e., The value \'Dad\' is assigned to a (new) variable called
+\'HouseCleaning\'.  In other words, putting a variable reference
+on the left-hand-side of an assignment like this allows you
+to access another variable which is named "indirectly".  You have
+to be careful when doing this, though.  Consider a similar, but
+slightly different example:
+.nf
+     CurrentTask    = House Cleaning   # This is fine
+     [CurrentTask]  = Dad              # Bad!
+.fi
+The reason this no longer works is that the indirect
+reference causes the second line to parse to:
+.nf
+    House Cleaning = Dad
+.fi
+This is illegal because whitespace is not permitted in variable names.
+\*(TC will produce an error if it sees such a construct.
+If you get into the habit of reading \'[something]\' as,
+"The current value of \'something\'" this whole area of variable
+naming and referencing will be easier to keep clear in your
+thinking.  See if you understand what the following does
+(if you don't, try it out with \'test-tc.py\'):
+.nf
+    foo   = 1
+    bar   = 2
+    [foo] = bar
+    [bar] = [foo]
+.fi
+You can get pretty creative with this since variable references
+can occur pretty much anywhere in an assignment statement.
+The only place they cannot appear is
+.B within
+another variable reference.  That is, you cannot "nest" references:
+.nf
+    # The Following Is Fine
+    FOO          = Goodness
+    BAR          = Me
+    Oh[FOO][BAR] = Goodness Gracious Me!
+    # But This Does NOT Do What You Might Think
+    [FOO[BAR]] = Something Or Other  # Avoid nested constructs like this!
+.fi
 .SS Lexical Namespaces
 The discussion of variable assignment and reference needs to be
 expanded now to include the idea of "lexical namespaces".  Think of a

Show line notes below