🚀 go-pugleaf

> How will Tcl change this...won't one still need to write
> the code to handle any commands it can receive?

True, but in TCL all the glue is there so that code gets called with an
already parsed argv.

> (True, you won't need to
> worry about receiving and parsing RexxMsgs, but once you have the code to 
> do this, it is fairly easy to drop into an application.)  

Yes, but with the code already written you can make sure that each program
supports a consistent syntax. This isn't such a big deal now, perhaps, but
look at all the UNIX commands that don't conform to any sane standard because
no standard argument parser existed.

Also, TCL is itself a nice language. Among other things, the user can easily
implement new control structures, just as you can in Lisp or Forth.

> I'm not try to be confrontational...just trying to understand why Tcl has
> such an advantage over ARexx, if it does.

I personally prefer TCL's command syntax, and I like the fact that I have the
source, and that I can easily extend the syntax of the language. I used to be
big on Forth, for much the same reason. The basic object in TCL is a string,
which can be interpreted as a list of strings.  The command structure in TCL
is also a list of strings...

For example, here's a TCL procedure that dumps one or more TCL procedures
to a file (taken from my browse startup file)

proc save {file args} {
	if { [length $args chars] == 0 } {
		print "# *** all procs ***" $file
		print \n $file append
		set args [info procs]
	} else {
		print [concat {#} $args] $file
		print \n $file append
	}
	foreach proc $args {
		set def [list proc $proc [info args $proc] [info body $proc]]
		print \n$def\n $file append
	}
}

Usage is: save file [proc]...
If no procs are specified, all current procs in the interpreter are dumped.
-- 
 _--_|\  Peter da Silva <peter@sugar.hackercorp.com>.
/      \
\_.--._/ I haven't lost my mind, it's backed up on tape somewhere!
      v  "Have you hugged your wolf today?" `-_-'