I've had a look at the Safe-TCL stuff, and frankly I'm a little unimpressed.
For the majority of "activation time" tasks, such as newsgroup votes, surveys,
asking simple questions on a form, Safe-TCL seems like a pretty huge
sledgehammer to do it with. There are some tasks that do indeed require the
power of a full programming language, but something simpler for the small
tasks would certainly be nice.
In my opinion, all this shows is that if you have not put much effort into
evaluating and experimenting with TCL, you really need to take the time and do
just that. The readily available implementation of TCL is small, quite
portable, well coded, and extremely easy to integrate into existing mail system
environments.
I speak as someone who was not involved in the specification of either TCL or
safe-TCL, and as someone who has successfully implemented safe-TCL extensions
to a mail system in a non-UNIX environment. It took me about two days to do it
the first time around (my implementation is a little out of date at present).
And I had to write the safe-TCL primitives myself. This is certain to change in
the near future.
TCL may be the simplest port I have ever done, and considering the fact that it
hasn't been ported to that many places, the simplicity is nothing short of
remarkable.
I don't think I would ever contemplate writing a Safe-TCL interpreter to
integrate with my Microsoft Windows MIME viewer, and I'm skeptical of finding
one for Windows that would be suitable. A simpler language has a much better
chance of being implemented by me, and in a seamless fashion that would look
much nicer than farming the program off to another program to be executed.
Well, there are two issues here. One is the base TCL language. I cannot imagine
it taking much more than a day or three to get it running in any reasonable
environment.
The other issue is TK. (For those of you that are unfamiliar with TCL and TK,
TCL is base language and TK is a set of extensions that provide a MOTIF-like
interface on X Window systems. This is a much nastier proposition if you're not
part of the X Window world. But any proposal that purports to provide a window
interface is going to be a pain. There's simply no way around it.
However, TK facilities are certainly not any sort of requirement. You can do
lots of stuff with safe TCL and no TK.
Here's some ideas. If anyone has done something similar, I'd certainly
appreciate hearing about it.
...
Actually, this is quite close to Pilot, a language that was developed because
BASIC was too complex ;-) And I really don't see how this set of commands is so
much simpler than core TCL.
As an alternative to defining "yet another language", I would entertain an
even smaller subset of Safe-TCL whose programs only contain calls to standard
Safe-TCL library functions for performing "choice", "reply", etc, so I
could just implement that bit of the language and farm more complex things
off to an external Safe-TCL interpreter.
If you haven't done so, you really, really, really need to take a close look at
the TCL implementation before making these sorts of assessments. It would
actually be significantly harder to do what you propose than to simply stick
with what TCL already provides.
Ned