[Richard Suchenwirth] 2003-03-20 - "Titoo" is a fancy spelling for T2, which is a language that doesn't exist (yet), but I started thinking about it this morning. Somehow like non-Euclidian geometry evolved by just changing one of the Euclidian axioms, the idea was of a language almost like Tcl, with one difference: "A command is evaluated in two steps. First, the Tcl interpreter breaks the command into words and performs substitutions as described below. These substitutions are performed in the same way for all commands. The '''second''' word is used to locate a command procedure to carry out the command, then all of the words of the command are passed to the command procedure." (Tcl has "the first word" - hence the name T2). The second position facilitates implementation of infix operators, in a way it's coming closer to [APL], but without limiting the number of arguments to 2 maximum. 

An exception would be if a command consists only of one word: then that of course is the name of the command, as it is in Tcl - so for instance [break], [continue], [return], [exit] would need no changes.

Just to get a feeling for that, here are some Tcl and T2 commands in comparison:
 set i 0                 | i set 0
 incr i                  | i incr
Obviously, the [set] command would in T2 better be called "="... and [incr] "++"?
                         | i = 0
 expr 1 + 2              | 1 expr + 2
This is pretty silly - better release [expr]'s operators from their dungeon, like many have done locally - a + command would add its first operand (to the left) with the second (to its right):
 + 1 2                   | 1 + 2
 expr {1+2}*{3+4}        | [1 + 2] * [3 + 4]
Like Tcl, T2 would have no operator precedence rules - explicit grouping would be required.

Some virtual code snippets how T2 might look:
 .. cd
 fp = myfile.txt open w
 fp puts "hello, file"
 fp close

 sum proc args {
   res = 0
   i in $args {res += $i}
   res =
 }
 sign proc x {
    {$x > 0} ? 1 : {$x < 0} ? -1 : 0
 }
 fac proc x {
    {$x < 2} ? 1 : {$x * [[x --] fac]}
 }
 i in [1 .. 10] {- puts $i}

Hmm.. what do y'all think?
----
[MSW]: You wrote 

 fp = myfile.txt open w
 
which due to your evaluation rule would mean (in tcl)

 set fp myfile.txt open w

which doesn't what you intended it to do; so either have the eval rule be applied recursively until arguments are exhausted, and thus takes away the possibility to use lists as arguments to procedures (hmm, it's broken in that respect already (talking about the 'args' argument)), or you use brackets - which themselves break your evaluation rule. so to get it right, it should look like this - or a bit similar

 set fp { myfile.txt [ {open w} ] }

or something like that (you wrote open first, but open must be second, its argument is w, which must be first; the open-bracket must be second etc. All in all this eval rule breaks passing of 'args' to commands, consider this

 open myfile.txt w

open takes two arguments. Now you have to group lists explicitely

 {myfile.txt w} open

back to the set fp thing, maybe I get it right now ?

 fp = {{myfile.txt w} open} []

this could be it ... ugh, isn't that ultra-ugly ?
----
[RS]: Indeed, but that wasn't my idea: rather, in the case of [open], to have the first to the left and the others to the right:
 myfile.txt open w
And yes, thought but unwritten was an explicit eval step in the = command; otherwise it should be
 fp = [myfile.txt open w]
The ''args'' argument is indeed manageable, but surprising:
 1 foo 2 3
would cause ''foo'' to be called with arguments {1 2 3}, which might end up in ''args'' if so defined.
----
[MSW]: having = an implicit eval step to the righthandside arguments would be confusing. [[ breaks the eval rule, too.
 fp = {myfile.txt open w} []
should be fully according to the evil rule, no ?
----
[MSW]: Urps. Freudian ... ''eval is evil'' *hum*. meant 'eval rule' of course