Question

I have a binary application that is statically linked against Tcl and the front end is the Tcl interpreter. I would like to offer users the capability of using Python to execute the same commands, as keyword options. A sample of the Tcl syntax is:

set_foo -foo 1.0 -bar 3.0 -cat x

so the python equivalent might look like this:

set_foo(foo=1.0, bar=3.0, cat="x")

Is it better to build the program twice, one as a Tcl app, one as a Python app? Or just keep everything as Tcl, and have a command that will invoke a Python script in its interpreter?

The commands are implemented in such a way in that they do not know anything about the scripting language used. The api is:

void set_fooCmd(Handler &data);

and the Handler is a C++ class which handles parsing the options and providing them to the command implementation. So far the Handler is implemented for Tcl, but not Python.

All of the code directly interfacing with Tcl is in its own directory, and abstracts away calls from the rest of the program.

Update:
This is not a duplicate question to:
Picking a front-end/interpreter for a scientific code

as they are asking whether to move from Tcl to Python or Matlab. I already know I want to support both Tcl and Python, and I would very much like to know what approaches people have used. Such as:

1. Calling a Python interpreter from Tcl
2. Compiling separate applications for a Python front end and a Tcl front end.
3. Some other approach.

Answer 1

Calling a Python interpreter from Tcl

Needless overhead.

However, Python’s tkinter module calls Tcl from Python. There is a precedent, but it seems convoluted to introduce too many interface layers.

Compiling separate applications for a Python front end and a Tcl front end.

This is very common. Many projects have multiple bindings — Python, Tcl, Perl, etc.

There is one possible way to slightly simplify the language binding.

1. Fix the binary app to work with simple text input and output. You will read from stdin and write to stdout.

2. Write Python (and Tcl) applications that gather the parameters, forks the binary as a subprocess; and write the parameters to the binary’s stdid and reads results from the binary’s stdout.