20040619 [CMcC]: A late night on [Tcl'ers Chat], some wild ideas, here's one:

'''What if Python had a new additional parser which made it look like Tcl?'''

I envisage it as follows:

   1. a line of input is broken up into elements, as per the [Endekalog].

   2. the 0th element of the resulting list is resolved as an object, or the name of an object

   3. the resolved object is inspected for a .__tcl__ method which is then called with the entire line as arguments.

   4. if there is no .__tcl__ method, the 1st element is treated as a method on the 0th object, and invoked on the object with the usual [Python] calling convention.

   5. the default .__tcl__ method calls the object with args 1..n with the usual [Tcl] calling convention.

There are assumed to be a bunch of objects inheriting from a TclCommand class, e.g. if foreach while set (etc etc)

Add [uplevel] to Python and voila - you have something which looks (very nearly) like Tcl, but is running over Python.

I really think this is feasible.  It could give you Tcl script level compatibility in Python, I think.

Let the games begin :)
----
''Interesting idea.  Note that there are also some deeper differences to mull over, such as copy-on-write (side-effect-less changes to lists), and the event model. -[jcw]''

As a thought experiment, it raises the question ''what is tcl?'' in a new context.

One could rename every command in the language, or change all of their conventions (say: 'proc' using mandatory indenting to indicate block nesting, IF expr lt.gt.eq - FORTRAN with line numbers.)  One could add GOTO to the language (with difficulty, admittedly) and turn it into BASIC

One could certainly remove the event model.  One could implement list operations as mutable ... would the result still be tcl, or not?  When would the result stop being tcl?

These are some of the issues that [RS]'s ''a little'' language experiments raise ... is tcl a language, or a way of implementing a language + a toolkit?

  -- [CMcC]