[jima] 2014-02-19 Novem is already in the works. Many proposals boil around it. I am thinking in what changes would have the most impact in how Tcl is perceived. Things like '''{*}''' indeed produced a visible change in Tcl as it modified how things looked for the coder at syntax level. Not long ago (2012 in Tcl time is not that much), http://www.tcl.tk/cgi-bin/tct/tip/401.html%|%TIP 401%|% was proposed to introduce yet another such word prefix '''{#}''', this one for comments, and with it the idea of a possible proliferation of {prefix} forms. In my mind the introduction of these prefixes only make sense if the goal is to enhance the way Tcl understands the data is being fed with. In the case of '''{*}''' it was a message of '''"a expanded list comes here"'''. For '''{#}''' the proposed message is, '''"this word you shall ignore"'''. Watching [JO] at the XXth conference it was clear to me that one of the main premises underlying Tcl was that each command is responsible for interpreting and processing the words which form its arguments. This is an awesome concept, or contract, as Tcl core is made conceptually oblivious to the works of an extension command. But, there are places where this contract proves a limitation. For instance, reading the efforts done in the [sugar] macro processor you can see how some commands ('''if''' and '''while''' for instance) need to be "better explained" to Tcl to facilitate the macro processor understand how it should handle its arguments. Perhaps '''sugar''' or the Tcl core for that matter would need to do better business with Tcl code (a sucession of Tcl commands, each one of them king to its own arguments) a little aid to just get the information needed to process the stuff. What information would be needed? Knowing that Tcl is really a nickname for at least three languages working in unison: that of Tcl scripts, that of Tcl expressions, and that of Tcl assembly language, suggest an answer. Perhaps it would be a good idea to annotate the arguments expected by a command in the following way: '''{=}''' would mean '''"this word is a Tcl expression"'''. '''{%}''' would mean '''"this word is a Tcl script"'''. Well, the semantics are not quite there, as the idea is that these prefixes will only be used to annotate arguments. So a single: ====== proc if { {=}expression {%}branch1 {%}branch2 } { ... } ====== Would provide enough information for other commands to grasp a better understanding of a command they might need to tweak on. The corresponding '''info''' subcommands would be giving information about what type each argument of a command is. ---- Going farther with the idea of {prefix} forms... it can be argued that type annotations, as in '''{double}''', '''{int}''' and such, might be handy... this seems excessive to me... what I propose is limited to what I think is a more fundamental level of the types a word can be in Tcl. [AMG]: I think you're better off creating a new command which lets you specify annotations. This command would normally be implemented as a total no-op: `proc annotate {args} {}`. But in an environment where the annotations are useful (e.g. with [Nagelfar] or some debugger or a documentation generation tool like [Ruff!]), this command would squirrel away its arguments in a place known to the interested framework. You could do this today without changing Tcl. An approach currently in use in many languages is having specially-formatted comments. Tcl lets you extract these comments from procs at runtime, and you can write code to parse them. Ruff! probably does this. I'm not sure how you get the text of the currently running script at runtime, but if the script is in a file, you just read the file. And if it's not in a file, why are you debugging or documenting it? Lastly, you can keep your annotations out-of-band, e.g. in a Nagelfar configuration file. ---- [PYK] 2014-09-04: I'm sure this idea has been proposed before by others, but as I mentioned in the [Tcl Chatroom] today, if a [namespace], e.g. `::tcl::rabbithole`, were reserved for the purpose, then commands like `=` and `%` could be defined inside it. Each command would take as its arguments both the word in braces and the word it prefixes, and return a list of words to be expanded into the command in place of the `{...}{...}` value. A namespace named `tcl::rabbithole` could be used to override the global commands. This would accomodate the proposal that is the subject of this page, but also leave the door open to the evolution of directives within this framework. `[{*}]` could be reimplemented in terms of this framework. Thus, there would be no net growth of the [dodekalogue], as rule 5 could be rewritten to describe the generalized form: '''Argument expansion''': When a word is prefixed by a word in braces, a command by the name of the word in the braces is resolved, first in `tcl::rabbithole` and then in `::tcl::rabbithole`. The command is executed with the word in braces and the prefixed word as its two arguments, returning a [list], the words of which are added into the original command in place of the original word and its braced prefix, with each word of the result becoming an individual argument to the command. This would subsume [TIP]s [http://www.tcl.tk/cgi-bin/tct/tip/293.html%|%293] and [http://www.tcl.tk/cgi-bin/tct/tip/401.html%|%401], and change the nature of other like-minded future TIPs such that they would simply be proposing new commands rather than new syntax. One feature that might be added via this mechanism is the oft-requested ability to traverse object chains syntactically from left-to-right rather than in the embedded fashion implied by Tcl: ====== set phone {.}{{$person1 employer} CEO phone} ====== `.` could be implemented to make the previous command equivalent to: ====== set phone [[[$person1 employer] CEO] phone] ====== ---- [jima] 2014-09-05: The thing is that then you need to make sure that `::tcl::rabbithole::.` does not use `{.}` otherwise you might end up in a recursive pit. [PYK] 2014-09-05: Yes, crafting `{...}` commands would require particular care to avoid that. `[{*}]` at least would be easily implemented, and available to other expanding commands: ====== proc ::tcl::rabbithole::* args {return $args} ====== ---- '''[ekd123] - 2014-09-05 13:05:06''' () might be a better choice, for it's only used for arrays and 99.9999% of the use doesn't have it in the beginning. {} will cause confusions. [PYK] 2014-09-05: That ship sailed when `[{*}]` was chosen as the expand syntax. [RLE] (2014-09-05): Yep, and couple that with the fact that "" is a valid array (or variable) name to Tcl and you have an incompatibility with using (): ====== $ rlwrap tclsh % set (something) "or another" or another % puts $(something) or another % unset "" % puts $(something) can't read "(something)": no such variable % set "" "this or that" this or that % puts ${} this or that % ====== There is a page or two on this Wiki (I can't pull them out of search right now) that discuss using the () array for proc options handling: ====== proc task { args } { array set "" $args if { $(-opt1) eq "something" } { do-something } set fd [ open $(-file) RDONLY ] ... } ====== [AMG]: If you're going to reclaim `$(...)` and break compatibility, I'm far, ''far'' more interested in using that notation as an [expr] shorthand. Let `$(...)` be the same as `[[expr {...}]]`. <>Suggestions