'''''Overview 20 Jan 2004'''''

While [Tcl] does have some facilities for metaprogramming
by virtue of the language, there are others that could
be added.

'''''Case 1'''''

Let's examine the use of the ''$'' substitution.

The [feather] extension proposes that the notation '''$text''' be
replaced with the subcommand syntax '''[[set text]]'''.

This is primarily to support the replacement of the ''set'' command and ensure that ''$'' behaves the same.

Let's take that one step further:

Consider the following pseudo scalar references:
    $Array($x)(y)($z)
    ${[somefunc $x y $z]}

None of the above can be used as references to scalar values in the current implementation of the parser.

'''''The parser'''''

Let's for a moment assume that parts of the internal parser are exposed to the script level.
We could then have the opportunity to plug in our references.
For example this may look like this:
     parser -char $ -replace {$([^ ]+)} -with {[set \\1]}
     parser -char $ -replace $([^(]+)\(([^,]+)\)\(([^,])+\)\(([^)]+)\)} -with {[araygetthree \\1 \\2 \\3]}
     parser -char $ -replace {$\{\[([^]])\]} -with {[funcset \\1]}


'''''Other Languages'''''

The usefullness of metaprogramming to emulate other languages is not quantified.
Personally I do not see the benifit of language emulation. 

Consider emulating forth; here is an example:

	2 dup + s" The answer is " s. .

This cannot be parsed by the tcl parser directly. The form:
    eval [join {2 dup + s" The answer is " s. .} \n]

would work for every token except ''s"'' as this is an immediate command that forward scans the text to the next ''"'' character. Thus the forth parser only sees ''s" s. .'' in the input.

Using the parser we may be able to install something like:
   parser -token s" -extend {[^"]*"}
   parser -eol { }

The use of ''[[subcommand]]'' notation would also have to have a mechanism to be overridden. This would complicate the expansion of ''$'' variables unless there were a '''-command''' option to the parser that forces evalution of the replacement text regardless of the meaning of '''[['''.

'''''Regular expressions'''''

The use of regexps in the example is for familiarity only. Regexps are useless for processing recursive, or paired (brackets within brackets et al.) definitions.

A more useful format would be [snobol] string matching, or Objective C selector/method encoding.

'''''Conclusion'''''

Given that the TCT are never going to make arrays first class variables, the ability to create new ''$'' variable encodings would go a long way to address programmers' desires to emulate them. It also allows the encoding of structures more efficiently as a call to ''[[func struct member]]'' can be more efficient than having to parse the array reference every access
(''example [[$dict member]] vs $array($y,member)'').

The ability to change the meaning of ''$'' notation would be a facile change to the core. Other substitions would require extensive changes to the parser and it is unlikely that this would be undertaken.
----
[RS] 2004-01-26: I'm not sure who wrote this page, but here's my comments:
   * Tcl started out with only [[set x]] for variable [dereferencing]. The $x shortcut was added later for convenience, and it sure is: 1 keystroke in place of 6...
   * Tcl [array]s are collections of variables, somehow like namespaces, but again with a simpler syntax: $x($y). For "first-class value" arrays, [dict]s will be ready from 8.5, and will take over much of what is being done with [array]s today. Also, [list]s are a good representation for many uses where other languages have (their) "arrays".
   * Being open source, everybody is free to take Tcl and modify it to his delight. But the TCT has to see that changes to the Tcl language do not make existing scripts break, and disappoint a considerable user-base worldwide.
----
[Category Concept]