: A late night on Tcl Chatroom
, 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:
- a line of input is broken up into elements, as per the Endekalogue.
- the 0th element of the resulting list is resolved as an object, or the name of an object
- the resolved object is inspected for a .__tcl__ method which is then called with the entire line as arguments.
- 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.
- 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)
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
- 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.
- 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
... 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
: 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.
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.)