ANN: Minotaur 0.1 - bridging Tcl, Python, and Perl

[Jean-Claude Wippler]

This is the first public announcement of a generalized extension which
lets you run Python scripts from Tcl, or Tcl from Perl, or any of the
other combinations.

Minotaur works by loading the appropriate shared library into another
script language's context.  So, for example, running Tcl from Python
means that the Python main program imports the Minotaur extension, which
in turn loads the Tcl libraries - thus Tcl becomes "embedded" into the
Python runtime environment (which is similar to embedding Tcl in a
normal C program).  As involved as that sounds, performance is already
surprisingly good, and the capability is turning out to be quite useful.

Minotaur 0.1 is an alpha level release, meaning: it works, aside from a
few quirks (see below), and bugs, but its API and implementation might
still change in incompatible ways in future releases.

An example, embedding a Tcl script in Python:
        import Minotaur
        Minotaur.initTcl()
        print Minotaur.Tcl("expr {1111 + 2222}")
        Minotaur.Tcl("""
            set result "Tcl version [info patchlevel]"
            Python "result = '$result'"
        """)
        print result

As you can see, a value is returned either directly (only if it's an
integer), or by using a reverse embedding, i.e. executing a Python
statement from the embedded Tcl system.  Also, this shows how tricky
quoting could get once you start mixing languages in this manner.  And
last but not least, note that the different language contexts are
separate: the two "result" variables used above are not related in any
way (one for Tcl, one for Python).  Also, Minotaur does not yet let you
share data, it merely lets you evaluate scripts (and copy things).

Now the gotcha's, quite a list of them right now:

- You need shared libraries to use Minotaur. Standard installations,
  especially of Perl and Python, do not always include these.  The
  Minotaur homepage has some info on rebuilds you might need to do.
- Tcl/Python can call Perl but to get results back, I had to introduce
  a secondary shared library, dynamically bound to the Perl runtime.
- There is currently no other interface than evaluating a single string.
  Passing int/string/whatever args efficiently is planned for later.
- The Minotaur extension has only been tested for Linux and Windows, but
  is built in a way which should also work on the Mac, and on all Unix
  systems, even those which do not support back-linking in shared libs. 
- Minotaur uses some global data; it's not yet re-entrant / thread-safe.
  As a matter of fact, Minotaur is still totally ignorant of threads.
- I have not yet succeeded in getting Minotaur working on the Mac, and
  ran into problems when trying to launch Tk from Python (Win/Linux).
- The current release does not include any Minotaur binaries, you may
  have to do quite a bit of tweaking to get this stuff to work for you.
  One of my plans is to substantially simplify deployment of all this.

And here's the fun part of things:

 - Minotaur uses Forth as low-level "super-glue" language.  This offers
   the ability to deal with all the inevitable "impedance mismatches"
   which will occur when crossing widely different software designs.
   Also, this can be done without compilation (and often portably).
 - Timing tests indicate that the overhead of calling through Minotaur
   is very low, when the necessary symbol lookups are done in advance.
   The C-based Forth in here uses pForth, and includes quite a bit of
   standard ("ANS") Forth for now, though this may change in the future.
 - The Minotaur extension is loadable from Perl, Python, and Tcl, 'cause
   it exports initialization calls for each of them.  This is essential,
   since the embedded language needs to reopen the extension to gain
   access to the same Forth context as the one which loaded it (this is
   how each embedded language can call back into its parent context).
 - Forth primitives have been defined which can open, lookup, and locate
   routines exported from shared libraries.  Due to the flexibility and
   performance of Forth, everything else needed to embed one language in
   the other is done in Forth, i.e. at run time.  Forth has no idea that
   it is being used to tie scripting languages together, for example.
 - Minotaur, and these shared library access functions have been tested
   on Linux, Windows, and Mac (partially).  The Forth code needed to
   implement such language bindings differs only in pathnames, so far.
 - But this is only the tip of the iceberg, really.  Proof-of-concept
   bindings have also been created for Java, MS COM, Lua, ICI, and PHP.

Minotaur is a spinoff of my long-term "TinyScript" project and is open
source, with a BSD-style license (do whatever you like with it, just
leave the copyright attributions intact, and don't sue me).  Minotaur
was written to see how far one could go in bringing scripting worlds
together, and to help me tie my own extensions into a range of languages
without having to write a whole range of interfaces.  It hasn't met this
goal yet, but my hope is that it will be of use to others and that a
number of language experts will extend and improve the mechanism so it
works well with all of them.

Minotaur has sort of a homepage here:
        http://mini.net/pub/ts2/minotaur.html
A mirror copy of my working area is being tracked here:
        http://mini.net/pub/ts2/  (a.k.a. ftp://mini.net/pub/ts2/)
And a snapshots of the whole area was recently created as:
        http://mini.net/pub/ts2-19990704.tar.gz

There is no documentation, release 0.1 is a "use the source Luke" kind
of project, but if you would like to try this out - or better still:
participate in whatever way you like - feel free to subscribe to the
Minotaur mailing list, by sending an email to minotaur-add at mini.net. 
There are a handful of subscribers now, with just a few outbursts of
discussions of where to take this, so far.  Which, at this stage, is
still a very open-ended question, IMO.

Comments, suggestions, praise, but especially offering to help with
whetever aspect of Minotaur you'd like to improve are most welcome. 
Language and platform bashing - yawn - will be redirected to /dev/null. 
If you wish to help lower language barriers, so that more code can be
re-used, more interfacing problems can be solved, and perhaps one day
even generic extensions can be written which serve multiple contexts,
please have a look at Minotaur and consider helping to make it happen.

One interesting option, would be to create a binding in SWIG which
generates the low-level glue to Forth, as well as language-specific
wrappers.  The key advantage is that this could let SWIG be used
entirely as a run-time tool, with no compiler/compilation in sight
(assuming the target library exists in shared library form, that is).

-- Jean-Claude Wippler <jcw at equi4.com>

P.S.  This announcement was posted to a range of newsgroups, but was not
      crossposted to avoid serving as flame bait for YAFLC (Yet Another
      Fruitless Language Comparison).  The list of newsgroups is:
		comp.lang.forth
		comp.lang.misc
		comp.lang.perl.moderated
		comp.lang.python
		comp.lang.tcl
      It's a lotta posting for such an early project, but that's because
      there seems to be no established "intra-lingual" newsgroup for
      this stuff.