control string replacement

6.2:
. notice tcl/tk and c are often passing strings to indicate code;
eg, f'open(name, "(r+, access=lock))
. these control strings are really lists of symbols not characters
so, instead of passing a char.string,
it should be a symbol atom "(r+),
or symbol list "(, ,,,) .

6.4:

. control strings entail a sublanguage, whereby
the server is parsing the string according to rules
shared between client and server .
. control strings may be given either as literals at compile.time,
or as char.string operations stored in char.string variables .
. a literal has 2 levels: a char.string is parsed into an etree
eg,
""( a char.string ) -- here is a string of char's starting with a space;
"( an etree ) -- here is an etree with 2 symbols .

. the use of char.string to convey parameters is not consistent with
the goal of having one universal language .
. it does not reuse available language parsers and debuggers;
and is therefore not as modular as possible .

. a server's definition of a control string
is similar to declaring parameter names:
it's declaring symbols that have a meaning specific to
the parameter record being applied during a call to the server .

. just as there is a way to declare formal param's,
the language needs a way to declare the allowed sublanguage
that will be assigned to the control.string parameter .
. the control.string's type is like a union:
it describes the varieties of etree that it's permitted to have .
. when etree is assigned to it, the compiler is called to check compatability;
. when char.string is assigned, it's parsed into etree and checked .
. that means when a control.string is being constructed dynamically,
the system designer doesn't have to consider how one is
constructing etrees rather than strings;
parsing is done generically, encoded to the widest possible dictionary
until it's been assigned to an environ such as a namespace or a control.string .