The Tao of Tcl

From news:comp.lang.tcl postings in May 2000:

 The Tao of Tcl (classic version):
    Everything is a string
    Every command is an argc/argv array of strings tied
       to a function.

 The Tao of Tcl (revised version):
    Everything gives the impression of being a string.
    Every command gives the impression of being an argc/argv
       array of strings tied to a function.

 The Torah of Tcl?:
    Tcl.n, steps 1-11.

 Enlightenment on demand, ;-)
 Mark.

 > Wonderful!  Please provide us with a pointer to this wonderful
 > achievement!

 Unfortunately, the Tao which is pointed to is not the Tao.
 How could it be otherwise?
 --
 Mark Harrison               markh@usai.asiainfo.com
 AsiaInfo Computer Networks  http://www.markharrison.net
 Beijing / Santa Clara       http://usai.asiainfo.com:8080

Some of Paul Duffin's thoughts on this are at http://people.manchester.ac.uk/~zzcgudf/tcl/future.html

- DKF In brief: see The Tcl way

Matt Newman adds:

 I always thought that one of the best kept secrets of the Tao of Tcl was
 that its really LISP!

 The Tao of Tcl (revised again)

    Everything is a list - pretending to be otherwise
    Every command is a (in list) -> (out list) + side effects

 Tcl -> LISP converter:
        s/[{\[]/(/g
        s/[}\]]/)/g
        s/([^a-z])?set(^[a-z])?/\1setq\2/g

 Actually having spent 9 years writing stuff like:

        eval $command insert end $args
 or
        eval [linsert $command end insert end "hello"]

 I find myself favoring the objv[0] is a list approach - it would  certainly
 clean up my code....

FW: Note that this type of code is much easier with 8.5, with the introduction of {*}, of course.

Paul Nash <webscool@ihug.co.nz> wrote the following in 2000 (or earlier, but that's as far back as the wiki history goes):

Allow Tcl to recognise objects and methods as the initial substring of a command. AS an example, the list object commands in Tcl do not conform to our OO ideals, we have [llength $a] instead of [list length $a]. (The reason being that the [list] command stole the thunder, but that is ancient history). The [string ...] commands are defined in accordance with OO ideals.

 "list length" $a

would be executed by the command interpreter as

 list length $a

but only if there is no [list length] command.

This mechanism already proliferates throughout Tcl/Tk. You can probably list many more examples off the top of your head than I know of. The treatment of [namespace inscope...] at the start of [unknown] is a good example of this type of code.

The process is called currying and is part of the process of lambda calculus, and all modern functional languages. It is known to provide complete computational complexity.

You don't have to look too hard to see that this process added to the command interpreter will add a couple of lines of code and no operational overhead. On the other hand it will save a lot of calls to [unknown]. All the lines of code of the type

 uplevel $initial_subcommand $args

and their associated code can be removed from everyones applications and extensions.

This also provides a mechanism for specifying OOP implementations, without having to get into the pragmatic arguments of inheritance, polymorphism etc.

I am not the only person to have made this observation, Alexandre Ferrieux came to the same conclusion independantly and posted to the c.l.t on "space commands", being command names with whitespace in them, which is the equivalent of an initial subcommand.

Cameron Laird has come to a similar conclusion independantly, though I dont know the context.

I dont have the email on my laptop with me, but the guy who wrote Feather looked at the lambda implementation and realised it was a better mechanism than he had acheived and he said he would change in his next rewrite.

Now for the hard part. Despite the fact that lambda calculus has been known for 50 years, modern languages like C have been around for 30, and functional languages for over 10 years, we still dont understand how to use the full range of computational complexity available to us. Adding this mechanism to Tcl would open a Pandora's Box of little understood possibilities, open to unlimites abuse in the form of obscure and unmaintainable code.

The process of compiling is hindered if the operation is not explicit in the code.

The issue of multiple substitution of the initial subcommand needs to be looked into.

Paradigms of good programming practice need to be established.

Backwards compatibility is not such an issue since the current command intepretation is a subset of the new one. However lots of issues would be raised as a result such as the [list] command. The mechanism would casue a major shakeout of all the inconsistancies which have developed both in Tcl, Tk and other extensions. It would commit the Tcl/Tk maintenance schedule to a major overhaul which would impact backwards compatability.

Tcl has the choice of biting this bullet or not. Failure to do so will make it dated in 10 years time, as a new generation of programmers familiar with functional languages develops. They will look at Tcl and see something limited and antiquated. Tcl being an intepretive language, they will expect it to take full advantage of the features which interpretation specifically provides.

I personally see Tcl's future strictly limited if it does not jump this hurdle.

LV Isn't it true that somewhere in the past few years, the bits needed to do this sort of thing have appeared in Tcl? I don't know how well known the mechanism is, or whether it meets the expectations of those who have felt the need, but I believe there is a mechanism now available.

RS: There are indeed more than this hurdle around. Tk also needs some face-lifting, and the major challenge will be those zillions of VB coders. If they see that "Tcl is good for you"... But seriously, I agree that [list length $x] is somehow better than [llength $x], but wouldn't [$x length] be even more in accordance with OO ideals? Call an object, tell it what to do? Makes it harder on compilers of course - but they're there for the hard work, after all...

FW: Though I would hate pointing to the Tao, I feel obligated to: in this case, the Tao is basically that which transcends dichotomies (hot/cold, night/day, whatever) and allows one to see everything neutrally of the various dichotomies, just to perceive it neutrally (to see its "true nature") and not the automatically stereotype it into all of its attributes. Tcl's typelessness is like this - dichotomies like string/int, string/list, string/hash etc. are just bluntly categorizing the True Nature of things, the Thing-As-it-Is of the string - the data we assign values to in code is textual, and to pretend otherwise is not the Tao. Tcl has by far the most Tao of any language I've seen (though I haven't looked at enough typeless languages, I'll admit).