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 [Endekalogue].

   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]''

   1. I believe Python gives you an ability to inspect the refcount on a list, if not it would be easy to do.  Then the set of commands where this would matter include [set] [lset] [lappend] and a few others.  They need to inspect refcount and copy before writing.

   2. Python has a complete event driven framework as a library, I believe you could integrate that to preserve the event driven model.

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?

[parsetcl] makes special cases of the following ''commands'': [if], [while], [for], [foreach], [catch], [proc] ... are these the only places where tcl's usual syntax is upset ... the only places where an [uplevel] would be needed to implement?  Are these the core syntactic commands?

''[Lars H]: The commands currently recognised by [parsetcl] are by no means the complete set, but merely those most common commands with script arguments that could be handled with a minimal amount of code ([switch] is missing since it would require a list-from-string parser). One of the beautiful things about Tcl is that one can create new control structures (see e.g. [returneval] and '''breakeval''' on the [return] page), so any reasonably generic mechanism for cross-referencing Tcl code would have to work from a database of commands that can be extended with the non-standard control structures that the code uses. Passing code as data is an important part of 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] - [RS]: I'd say Tcl is just both - "The chameleon language"... Tcl gives me so much freedom as no other language has before.

----
Another thing this thought experiment suggests is that tcl has a metasyntax, in that it would seem to be possible to actually '''embed''' many languages at a tcl syntactic level without using the tcl core at all.  I leave [PERL] as an exercise for the demented.

----

[Scott Nichols] It's Defiantly possible. Developers have done similar things for Java [JACL]. The company I currently work for is using JACL with JavaServer pages. I guess the idea was it would be easier for someone to learn Tcl than JavaServer pages.

[CMcC] I just wrote a stand-alone lexer for Tcl in http://sharedtech.dyndns.org/~colin/tclparser.tar.gz - handles the Endekalogue, generates a tree (could do anything - call Python, as detailed above, for example.)