Version 6 of Annotating words for better specifying procs in Tcl9

Updated 2014-09-05 13:14:53 by pooryorick

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), 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.


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 TIPs 293 and 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 equivalant 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.


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.