Well, for my purposes I'll probably have to write the interpreter from
scratch, even if the publicly available one was the bees-knees in terms
of portability and embedibility. My requirements for embedded interpreters
are a lot stricter than most people's:
As I said before, you really need to take a look at the code before determining
whether or not your requirements can be met.
(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".
This isn't directly supported, but it would be fairly easy to implement as long
as the granularity doesn't have to be too fine. If the granularity is too fine
it would be easier to simply implement a coroutine facility with separate
stacks and use that. (On NT you'd be foolish not to avail yourself of the
facilities provided by the operating system for this stuff.) TCL has no problem
with coroutines (see the next point).
(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).
There are no practically no globals in TCL: It is either reentrant
out-of-the-box or so close to it that the necessary changes are trivial. (I no
longer remember whether or not I had to change anything to meet my reentrancy
requirements, which are pretty close to absolute. I don't believe I did, but I
might have forgotten something. I know I didn't have to use any semaphores --
I'd remember having done that. So if there was anything to change it was pretty
trivial. Please note that I'm ignoring X Window issues here -- they complicate
things considerably for reasons that have nothing to do with TCL.)
Remember that TCL is designed to be an embedded extension language so being
able to achieve full reentrancy is an absolute requirement much of the time.
TCL would not be a useful embedded language if extending one set of routines
with TCL precluded using another TCL-extended set of routines in the same
application. As a result TCL fully supports multiple, separate, possibly
concurrent, interpreters. Not only is this the rule rather than the exception
for TCL applications, the whole safe-TCL design depends on being able to have
two completely separate interpreters simultaneously.
This is also an absolute requirement in my environment for other reasons, so I
know for a fact that this can be done.
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.
Well, what can I say? While UNIX is not the environment I usually program in, I
actually have done a lot of programming on UNIX over the years. My code as a
rule is fully reentrant and supports multiple simultaneous invocations from
separate callers in the same process. I've been using coroutines and similar
mechanisms on UNIX and other systems for 10 years now -- long before POSIX
threads provided an excuse for coding things right.
I will agree that a lot of UNIX code is not reentrant and really should be, and
Dr. Ousterhout deserves high marks for having created such a clean, portable
piece of code, but come on! This just isn't *that* remarkable. There's plenty
of other clean code out there, and one should not assume that everything is
dreck until proven otherwise.
- 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.
If you're talking about TCL, I think you're wrong. If you're talking about TK,
you're absolutely right, but for reasons that have nothing to do with the
design of TCL.
Ned