Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!uwm.edu!zaphod.mps.ohio-state.edu!mips!apple!sun-barr!rutgers!njin!limonce From: limonce@pilot.njin.net (Tom Limoncelli) Newsgroups: comp.sys.amiga.tech Subject: Re: Tcl - Tool command language Message-ID: Date: 1 Mar 90 21:12:04 GMT References: <5213@sugar.hackercorp.com> Organization: Drew University/NJIN Lines: 52 TCL was presented at Usenix this January by Dr. O. himself. I was very impressed. Yes, it overlaps with REXX's purpose, but it "fits" into Unix a lot nicer. (IMHO) The main difference between TCL and REXX is TCL gets linked into your code and does all the parsing, etc. for you. It handles loops, etc. When it needs one of your commands executed, it calls one of your routines (you must have "registered" the name of the command, how many parameters it takes, the memory location to start executing, etc). On the other hand, REXX takes a less-active role. You implement your own macro/script language and call REXX when you don't know how to interpret something. A full description of TCL is available in the Usenix January '90 preceedings. [NOTE: The below is semanticly imprefect... take it with a grain of salt and try to understand my point, rather than picking on my semantics. ] It really fits into "The Unix Way" very well. Remember when Unix was new and consisted of many small tools working together? Now there are so many "big" applications; with the rationalization that interactive tools don't "pipe" too well. Well, TCL could bring Unix full-circle again and let even interactive programs work with other programs. That is, working together to make a bigger system; like pipes still do for non-interactive work. (Grain-of-salt mode OFF) Two noteworthy topics: (1) after the Tcl paper was presented at Usenix; when anyone else was asked if their software had a scripting language they either said, "no, but now I plan on adding Tcl" or "Yes, but I'm ripping it out to add Tcl as soon as I get home." (2) A person asked him, "Is it so small because a comittee didn't design it?" (and got a big laugh) I was considering porting the code over my next break. Though I wouldn't want it to compete with AREXX, I have thoughts on how to make it work with AREXX, not against it. Basically, I see it as a parser that programs can "plug-and-chug" to get a script language, a parser, and a gateway to AREXX. If I can make it a .library, it would make adding an internal scripting language w/AREXX port easier for developers. -Tom -- Tom Limoncelli The computer industry should spend more time in front of tlimonce@drew.uucp their computers. Remember when "Look & Feel" tlimonce@drew.Bitnet was what you tried to do on a date? limonce@pilot.njin.net