Excerpts from mail: 24-Nov-93 Re: Enabled mail
rhys(_at_)cs(_dot_)uq(_dot_)oz(_dot_)au (2170)
My requirements for embedded interpreters
are a lot stricter than most people's:
(a) It can't take over the machine when running a script. It must
periodcally return back to the Windows event loop to allow other
things (maybe even other language interpreters embedded in the
same program) to execute. Note: this is different to having the
script call the event loop periodically for Tk programs.
"Returning back" changes the code structure quite a bit from
"calling out".
I don't think this is a problem with the latest versions of Tk. John
has separated things nicely now, so that if you want the standard main
loop you get it, but if not, you just provide your own version of
tkMain.c. You can basically just copy the default one, but replace the
call to Tk_MainLoop() near the end with a main loop of your own
choosing, possibly based ins ome part on the source code for
Tk_MainLoop(). Of course, all this assumes that you're going to be
trying to port Tk to Windows. If you're just using Tcl, I think it's
even easier.... but eventually you'd want to help define a
SafeTcl_InterfaceStyle value for Windows user interface programming.
(b) It must be able to run more than one script at a time, each
in its own separate "address space". (And, no cheating with
"fork" because Windows 3.x has no such animal).
If the standard TCL interpreter does this, then I want to shake Docter
Ousterhout's hand, because he is the only Unix programmer in the world
that I know of that goes to this much trouble.
As Ned implied, I think you'd better be prepared to shake that hand. If
I understand you correctly, this is trivial -- you just create mutliple
Tcl_interp objects. In fact, the Safe-Tcl interpreter already uses 2 of
these, one for trusted programs and one for untrusted programs.
- It is very portable having been ported into many non-Unix environments.
The only problem with the portability is that Dr. Ousterhout hasn't folded
those changes into the mainstream code.
Portability to Windows is a whole new ball game.
So is dealing with John Ousterhout's code. I thought I knew a lot about
making code portable, having first had to deal with porting the
incredible non-Andrew system to various platforms, and then trying to
make metamail run in a wide variety of environments, but Tcl really put
me in my place. Check it out, for sure.
As for the question of your writing your own Tcl implementation, I'm
actually very pleased to hear that you might do that. Not that I
necessarily agree that it's the smartest use of your time on your own
project, but the truth is that Ousterhout's implementation is so good
that I had begun to wonder if there ever WOULD be a second
implementation, which I think is a very good idea in principle. I'll be
interested to see how it goes! -- Nathaniel