karl@sugar.hackercorp.com (Karl Lehenbauer) (02/27/90)
The following text was extracted from documentation that came with
the release of Tool command language I indirectly acquired from its
author, Dr. John Ousterhout of the University of California at Berkeley.
If this looks interesting to you, you may be interested in getting a
copy of the alpha release of a port of this package over to the Amiga.
The README file for Amiga Tcl follows the overview.
If you would like me to email you a copy of the alpha release, please
let me know. If a lot of people ask for it, I'll post it to
comp.sources.amiga. (If you're not willing to do some hacking on it,
it'd probably be best to wait for the beta release, at the very least.)
Regards,
Karl Lehenbauer, Hackercorp, 3918 Panorama, Missouri City, TX 77459
Tcl - overview of tool command language facilities
INTRODUCTION
Tcl stands for ``tool command language'' and is pronounced
``tickle.'' It is actually two things: a language and a
library. First, Tcl is a simple textual language, intended
primarily for issuing commands to interactive programs such
as text editors, debuggers, illustrators, and shells. It
has a simple syntax and is also programmable, so Tcl users
can write command procedures to provide more powerful
commands than those in the built-in set.
Second, Tcl is a library package that can be embedded in
application programs. The Tcl library consists of a parser
for the Tcl language, routines to implement the Tcl built-in
commands, and procedures that allow each application to
extend Tcl with additional commands specific to that
application. The application program generates Tcl commands
and passes them to the Tcl parser for execution. Commands
may be generated by reading characters from an input source,
or by associating command strings with elements of the
application's user interface, such as menu entries, buttons,
or keystrokes. When the Tcl library receives commands it
parses them into component fields and executes built-in
commands directly. For commands implemented by the
application, Tcl calls back to the application to execute
the commands. In many cases commands will invoke recursive
invocations of the Tcl interpreter by passing in additional
strings to execute (procedures, looping commands, and
conditional commands all work in this way).
An application program gains three advantages by using Tcl
for its command language. First, Tcl provides a standard
syntax: once users know Tcl, they will be able to issue
commands easily to any Tcl-based application. Second, Tcl
provides programmability. All a Tcl application needs to do
is to implement a few application-specific low-level
commands. Tcl provides many utility commands plus a general
programming interface for building up complex command
procedures. By using Tcl, applications need not re-
implement these features. Third, Tcl will eventually
provide a mechanism for communicating between applications:
it will be possible to send Tcl commands from one
application to another. The common Tcl language framework
will make it easier for applications to communicate with one
another. The communication features are not implemented in
the current version of Tcl. [The Amiga version of Tcl
does support interapplication communication -karl]
----------
TclaREADME
----------
This is the alpha distribution of Tcl and Tcla. Tcl stands for Tool
Command Language, and was created by Dr. John Ousterhout of the
University of California at Berkeley as a library package to be
embedded in various tools (editors, debuggers, terminal emulators, etc)
as the tools' command interpreter. Tcl provides a simple programming
language, a set of built-in commands, and has a C interface that
tools can use to add application-specific commands to the base set
provided by Tcl.
Tcla stands for Tool Command Language -- Amiga, and it provides several
commands (via the C interface) that have been added to Tcl to support
Amigas, including support for CLI commands, windows, menus, resources,
file requesters, alerts and message passing between Tcla programs.
Tcla was created by Karl Lehenbauer of Hackercorp.
This package contains both Tcl and Tcla. Tcl is essentially original Tcl,
with a small number of changes described below. Tcl is copyrighted by
the University of California, but their copyright allows for reuse for any
purpose, including commercial sale, subject to the restriction that the
copyright and disclaimer messages must be included unmodified where present
(i.e. in the source code). Likewise, Tcla is copyrighted by Hackercorp,
but we also allow redistribution for any purpose subject to the same
requirements regarding copyright and disclaimer messages.
Tcl and Tcla are compiled into libraries. The TclTest C program, included
with Tcl, and the various test and demo C programs included with Tcla
can be linked with these libraries to produce executable programs that have
built-in Tcl interpreters, and at the programmer's option, Tcla extensions can
be included in one's programs to add Tcl command support for the CLI, windowing,
file requesters, alerts, menus and resources. Further, Tcla programs have the
ability to send and receive Tcl commands to and from other Tcla programs.
Tcl and Tcla should compile without trouble on Manx Aztec C 5.0a or later.
A port to Lattice should not be too difficult, the main work will probably
changing the makefiles, but this has not been done at the time of this
writing.
Changes in Tcl from Tcl as provided by John Ousterhout/Berkeley:
o In original Tcl assigning an empty string to a variable caused
that variable to cease to exist, resulting in an error when you
tried to reference it. This broke all sorts of little Tcl
programs that should have worked.
Peter da Silva came up with changes to fix this, and Amiga Tcl
incorporates this change. The changes been forwarded to John
Ousterhout (they were minor) and we expect that he will adopt
them.
o As a positive side effect of the above change, Tcl procedures that
can accept a variable number of arguments can now be called with
no arguments. Previously if you defined a Tcl procedure as taking
a variable number of arguments, it required that at least one
argument be passed. This restriction was not true for C extensions,
so now neither C extensions nor high-level Tcl procedures require an
argument when the procedure expects a variable number of arguments.
o The exec command has been removed. This routine is system
dependent, and is now provided by the Tcla library.
o ANSI function prototypes have been generated and are used to
enable type-checking when compiling Tcl and Tcla. The tcl.h
and tcla.h include files declare function prototypes for all
C-callable Tcl and Tcla support routines to help insure
their correct usage.
o Original Tcl did not concern itself with running out of memory.
This is understandable as it was developed and used on a virtual
memory machine (VAX) running Unix. On the Amiga we have to be
more careful, because running out of memory is not such an uncommon
occurrence. (This is an area within Tcl/Tcla that still needs
work.)
o The panic routine that comes with Berkeley Tcl is present but
is not included in the Tcl library. Users can provide their
own panic routine (both Tcl and Tcla library routines call
panic when they encounter various unrecoverable conditions) or
use the one that is included in the Tcla library (the default).
The Tcl documentation consists of the Tcl manual and the Tcl C-interface
routines. The file tcl.1 and all of the xxxx.3 files are Unix nroff/troff
files prepared using the "man" macros (nroff -man tcl.1, etc). The manual
and C-interface documentation is also provided as a straight ASCII text file
(tcl.man and tcl.cman) for those who don't have access to Unix or otherwise
don't care to nroff the manuals themselves. (Note that the ASCII versions
have been stripped of all overstrikes, etc, so if you have nroff or troff
you may want to go ahead and use them to get listings with overstrikes, etc)
Known Bugs In Alpha Release
---------------------------
Some Tcla routines have some global data that should be instantiated
within the interpreter environment via the ClientData structure but
isn't. Fixing this will also mean that in a future release the
initialization routines will require an argument of a pointer to the
interpreter into which they are being instantiated. PLEASE DO NOT
GENERALLY DISTRIBUTE CODE OR PACKAGES BASED ON THE ALPHA RELEASE. WE
DO NOT WANT TO HAVE TO MAINTAIN BACKWARD COMPATIBILITY TO THE MANY
BRAIN-DAMAGED ASPECTS OF THE ALPHA RELEASE.
All of the routines to support windowing and menus are experimental. They
do not support all the capabilities of Amiga windowing, menus, etc, by any
stretch of the imagination.
Menus only work for one window. (A serious problem... fix is in the works)
The intertask communications code works but doesn't always return all memory
used. (A fix is being worked on.)
Tcla documentation is sparse.
The current Tcla event loop handling code is insufficient for complicated
tasks. Users needing complex event loops will have to "roll their own",
using loop.c from the Tcla library source as an example for how to include
Tcla support in their loop.
The Tcl "exec" and "run" commands contain a great deal of common code
that should be extracted into a third routine.
Reporting Bug Fixes And Distributing Changes
--------------------------------------------
Please report bug fixes back to Hackercorp so that we may include them in
future releases.
Please don't release your own incompatible "core" version of Tcl unless
you have tried to contact us to get us to incorporate your changes or
enhancements and found us unresponsive.
Wish List
---------
There is a lot of work to be done. Here is my wish list:
o Most pressing is probably to make Tcla into a shared library,
so only one copy will be resident. Right now, having several
programs with Tcl interpreters chews up a lot of memory.
o An ARexx interface. Tcl looks to provide some tremendous
intertask communications capabilities, and is very simple
to use. Nonetheless, ARexx already has become pretty standard
on the Amiga. Well, we can have both if code is written to
pass messages between them, and Tcl looks to be an easy way
to provide a command interpreter for your ARexx port.
--
-- uunet!sugar!karl "As long as there is a legion of superheros, all else
-- can surely be made right." -- Sensor Girl
-- Usenet access: (713) 438-5018cmcmanis@stpeter.Sun.COM (Chuck McManis) (03/01/90)
In article <5213@sugar.hackercorp.com> (Karl Lehenbauer) writes: >The following text was extracted from documentation that came with >the release of Tool command language I indirectly acquired from its >author, Dr. John Ousterhout of the University of California at Berkeley. Ok Karl, sounds like Dr. Ousterhout has re-invented REXX. Possibly not a bad thing, but in the wish list you want an "ARexx interface" so I'm confused somewhere. Can you compare and contrast the REXX and TCL languages, their semantics, and the ease of extending/using them in one's applications? Since ARexx will be included in 1.4 (according to published accounts in various magazines and on BIX) how does TCL help the Amiga (rather than fragment what support is already building for ARexx) ? Has Dr. Ousterhout published anything on TCL yet ? If so where ? Lots-o-questions. --Chuck McManis uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcmanis@Eng.Sun.COM These opinions are my own and no one elses, but you knew that didn't you. "If it didn't have bones in it, it wouldn't be crunchy now would it?!"
peter@sugar.hackercorp.com (Peter da Silva) (03/01/90)
In article <132344@sun.Eng.Sun.COM> cmcmanis@sun.UUCP (Chuck McManis) writes: > Ok Karl, sounds like Dr. Ousterhout has re-invented REXX. To a certain extent, yes. But there are some big differences between REXX and TCL. First of all, the source to TCL is freely available. Secondly, the TCL-C interface is a lit simpler and cleaner than the REXX-C one, and you get TCL messages already parsed... to add a REXX interface to a program requires that you implement your own command language first. On the down side TCL is newer and hasn't been library-ised yet. REXX is a baby-PL/I. TCL is a string-oriented language with some similarity to lisp. On UNIX, I have integrated TCL and my UNIX version of Browse... here's part of the startup file for browse: proc key_'d' {} { if { [string compare d [get key -d-]] == 0 } { set file [target] set prompt [concat Delete $file {? }] if { [string match {[yY]} [get key $prompt]] } { if { ![eval [concat browse delete $file]] } { perror } } } } proc key_'r' {} { set file [get file .] set prompt [concat Rename $file {to }] set new_file [get response $prompt $file] if { ![browse rename $file $new_file] } { perror } } Here's how you add a command to TCL, from the example code: int cmdSleep(clientData, interp, argc, argv) ClientData clientData; /* Not used. */ Tcl_Interp *interp; int argc; int *argv; { int count; if (argc != 2) { sprintf(interp->result, "wrong # args: should be \"%.50s seconds\"", argv[0]); return TCL_ERROR; } count = atoi(argv[1]); sleep(count); return TCL_OK; } main() { interp = Tcl_CreateInterp(); Tcl_CreateCommand(interp, "sleep", cmdSleep, (ClientData) "sleep", NULL); ... -- _--_|\ 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?" `-_-'
deven@rpi.edu (Deven T. Corzine) (03/02/90)
Hey! I was gonna do that! I've been beaten to it.... :-/ Deven -- Deven T. Corzine Internet: deven@rpi.edu, shadow@pawl.rpi.edu Snail: 2151 12th St. Apt. 4, Troy, NY 12180 Phone: (518) 274-0327 Bitnet: deven@rpitsmts, userfxb6@rpitsmts UUCP: uunet!rpi!deven Simple things should be simple and complex things should be possible.
rlr@stcvax.STORTEK.COM (Roger Rose) (03/02/90)
In article <132344@sun.Eng.Sun.COM>, cmcmanis@stpeter.Sun.COM (Chuck McManis) writes: > In article <5213@sugar.hackercorp.com> (Karl Lehenbauer) writes: > >The following text was extracted from documentation that came with > >the release of Tool command language I indirectly acquired from its > >author, Dr. John Ousterhout of the University of California at Berkeley. > > ... Since ARexx will be included in 1.4 (according to > published accounts in various magazines and on BIX) how does TCL help > the Amiga (rather than fragment what support is already building for > ARexx) ? Has Dr. Ousterhout published anything on TCL yet ? If so where ? > Lots-o-questions. Dr. Ousterhout presented a paper on TCL at the Winter '90 USENIX. It provides a good technical overview of the functionality and CPU timings for various operations (on a uVAX, I believe). (I don't recall if the IPC semantics were fully described in the paper.) I haven't seen ARexx, so I can't really perform a comparision. The main thing that made TCL interesting in a "what does it buy us" sense was the excitment it generated amongst the attendees. Everyone wanted a copy. If this is the case, we may be seeing packages where the interface language and the IPC facilities are handled by TCL. (There is already an X-based/TCL IPC facility.) -- Roger Rose UUCP: {ncar ico}!stcvax!rlr -or- rlr@stcvax.stortek.com USnail: Storage Technology Corp. - MS1169 / Louisville, Co. 80028-1169 phone: (303) 673-6873
limonce@pilot.njin.net (Tom Limoncelli) (03/02/90)
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
chrisl@caen.engin.umich.edu (Chris Lang) (03/02/90)
In article <5231@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: >In article <Mar.1.16.12.03.1990.15155@pilot.njin.net> limonce@pilot.njin.net (Tom Limoncelli) writes: >> 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. > >Basically, that fits in well with our view. The big problem I see with >REXX is that it needs each application to implement their own scripting >language anyway, which is an uncool duplication of effort. This fills >that gap nicely. >-- > _--_|\ Peter da Silva <peter@sugar.hackercorp.com>. I'm not sure what that means. True, with ARexx the developer needs to write code to handle all the commands the application can receive from an ARexx script/program, but this hardly the same as writing an entire scripting language, is it? How will Tcl change this...won't one still need to write the code to handle any commands it can receive? (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.) I'm not try to be confrontational...just trying to understand why Tcl has such an advantage over ARexx, if it does. -Chris ----- Chris Lang University of Michigan, College of Engineering home: 4622 Bursley work: National Center for Manufacturing Sciences Ann Arbor, MI 48109 900 Victors Way, Suite 226 (313) 763-1832 Ann Arbor, MI 48108 chrisl@caen.engin.umich.edu (313) 995-0300 "I hate quotations. Tell me what you know." - Ralph Waldo Emerson
peter@sugar.hackercorp.com (Peter da Silva) (03/02/90)
Hey man, your mission is getting UNIX emulation under AmigaOS. Don't sweat
the small stuff...
--
_--_|\ 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?" `-_-'peter@sugar.hackercorp.com (Peter da Silva) (03/02/90)
In article <Mar.1.16.12.03.1990.15155@pilot.njin.net> limonce@pilot.njin.net (Tom Limoncelli) writes: > 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. Basically, that fits in well with our view. The big problem I see with REXX is that it needs each application to implement their own scripting language anyway, which is an uncool duplication of effort. This fills that gap nicely. -- _--_|\ 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?" `-_-'
mwm@raven.pa.dec.com (Mike (Real Amiga have keyboard garages) Meyer) (03/03/90)
Enough. The following two false statements have been made, and need to be corrected. 1) "ARexx is a mini PL/I". Not anymore than TCL is "a mini shell". The two have some syntactic relationship to the "more complete" language; that's about where the similarity to it's parent language ends. Both have roots in other languages as well, and both look like they can do the job intended for them pretty weel. 2) "ARexx requires the programmer to provide a scripting language." A half-truth, at best. ARexx requires a command line interpreter, which is a much less complicated beast. For example, treewalk makes quite effective use of an ARexx interface. It's got no scripting language whatsoever - all it knows how to do is parse expressions. And we have a false implication. 3) "TCL does all the parsing, handles loops, etc", with the implication that ARexx doesn't do any of this. Again, 1/2 true. ARexx provides loops, variables, and all the hard part of the scripting language. You do have to provide a command parser. There are advantages & disadvantages to both approaches. The Usenix article is inadequate for doing a real comparison. I'm getting a copy to look at, and may have more to say later. However, I suspect that it'll have much the same problem Rexx does - most tcl programs are dependent on the application they talk to, and won't port very well because of this (unless the application runs in both places). Rexx is powerful enough that people are writing "real" (as opposed to macro for them) applications in it, so there is interest in ports to other places (the call for a Unix Rexx on comp.lang.rexx is a monthly event). I don't know if this is true for tcl or not, but time will tell us that one. <mike -- My feet are set for dancing, Mike Meyer Won't you turn your music on. mwm@berkeley.edu My heart is like a loaded gun, ucbvax!mwm Won't you let the water run. mwm@ucbjade.BITNET
mwm@raven.pa.dec.com (Mike (Real Amiga have keyboard garages) Meyer) (03/03/90)
Enough. The following two false statements have been made, and need to be corrected. 1) "ARexx is a mini PL/I". Not anymore than TCL is "a mini shell". The two have some syntactic relationship to the "more complete" language; that's about where the similarity to it's parent language ends. Both have roots in other languages as well, and both look like they can do the job intended for them pretty weel. 2) "ARexx requires the programmer to provide a scripting language." A half-truth, at best. ARexx requires a command line interpreter, which is a much less complicated beast. For example, treewalk makes quite effective use of an ARexx interface. It's got no scripting language whatsoever - all it knows how to do is parse expressions. And we have a false implication. 3) "TCL does all the parsing, handles loops, etc", with the implication that ARexx doesn't do any of this. Again, 1/2 true. ARexx provides loops, variables, and all the hard part of the scripting language. You do have to provide a command parser. There are advantages & disadvantages to both approaches. The Usenix article is inadequate for doing a real comparison. I'm getting a copy to look at, and may have more to say later. However, I suspect that it'll have much the same problem Rexx does - most tcl programs are dependent on the application they talk to, and won't port very well because of this (unless the application runs in both places). Rexx is powerful enough that people are writing "real" (as opposed to macro for them) applications in it, so there is interest in ports to other places (the call for a Unix Rexx on comp.lang.rexx is a monthly event). I don't know if this is true for tcl or not, but time's got that anser. <mike -- It's been a hard day's night, Mike Meyer And I been working like a dog. mwm@relay.pa.dec.com It's been a hard day's night, decwrl!mwm I should be sleeping like a log.
peter@sugar.hackercorp.com (Peter da Silva) (03/03/90)
In article <MWM.90Mar2120356@raven.pa.dec.com> mwm@raven.pa.dec.com (Mike (Real Amiga have keyboard garages) Meyer) writes: > Enough. The following two false statements have been made, and need to > be corrected. I'm sorry you interpreted my remarks as an attack on REXX. That was neither intended nor implied. I'm sorry if my casual and imprecise manner of writing has caused umprage. Let me take this opportunity to expand on my statements. REXX syntax and structure is based on that of PL/I, which is fine. Most of the REXX users I know are IBM mainframe types, and that's where I got the "mini PL/I" phrase. TCL is more like a cross between AWK and Lisp, in that context. And AWK in turn is a baby C. Given the attitude many people appear to have towards C I can't say which of these has the "advantage" here. > 2) "ARexx requires the programmer to provide a scripting language." OK, Arexx requires the programmer to provide a command line interpreter. TCL is a fine command line interpreter. REXX -- meet TCL. TCL -- meet REXX. May you be very happy together. -- _--_|\ 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?" `-_-'
louie@sayshell.umd.edu (Louis A. Mamakos) (03/03/90)
What I'd really like is an implementation of PERL as a scripting language and tool for the Amiga. There was a port of PERL version 1.x a few years back; an AREXX like IPC interface to a PERL interpreter with all of its regex stuff would be really fun..
papa@pollux.usc.edu (Marco Papa) (03/03/90)
In article <5231@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: >Basically, that fits in well with our view. The big problem I see with >REXX is that it needs each application to implement their own scripting >language anyway, which is an uncool duplication of effort. This fills >that gap nicely. I just got Dr. Ousterhout's paper from Karl and I am very impressed. We are DEFINITELY going to use Tcl for "another" platform that doesn not have AREXX, but are also seriously considering incorporating Tcl into A-Talk III's script language, maintaining the current Arexx compatibility. Thoughts? -- Marco -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= "Xerox sues somebody for copying?" -- David Letterman -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
limonce@pilot.njin.net (Tom Limoncelli) (03/04/90)
Let me re-phrase what I said.
The part about "small tools working together" still holds. AREXX
and Tcl both provide that kind of thing.
AREXX sits outside the applications and sends commands in. Tcl sits
inside the applications and, when needed, can send a command to
another Tcl-based application.
With AREXX, you have one interpreter that executes commands. Certain
commands are "sent" to programs that will do that function for that
command. In other words, the more AREXX compat. applications you are
running, the more commands get added to the interpreter. (Well, not
directly added, but in a certain sense the vocabulary is enhanced.)
Tcl becomes the script language for your application. It includes all
the usual looping commands and everything that you expect. You then
add new commands to it's language. For example, if you wanted a
Tcl-based mail reader, you'd write the various components, and link in
the Tcl module. ...and your code would start with a call to:
Initialize-all-Tcl-stuff();
followed by a
AddThisCommand("read", readroutine, HowManyParameters);
and a
AddThisCommand("create", createroutine, HowManyParametersForThis1);
Now, this build-in interpreter has the ability to do use your routines
too.
So, one is better if you like central authority and one is better if
you want your programs to be egalitarian. :-) They'll both get the
same thing done. With sharable libraries they both take about the
same amount of space (linear expansion) though I've been told that
AREXX is a larger interpreter.
-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.netmwm@raven.pa.dec.com (Mike (Real Amiga have keyboard garages) Meyer) (03/04/90)
In article <5232@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: In article <MWM.90Mar2120356@raven.pa.dec.com> mwm@raven.pa.dec.com (Mike (Real Amiga have keyboard garages) Meyer) writes: > Enough. The following two false statements have been made, and need to > be corrected. I'm sorry you interpreted my remarks as an attack on REXX. That was neither intended nor implied. I'm sorry if my casual and imprecise manner of writing has caused umprage. Let me take this opportunity to expand on my statements. No, I didn't interpret them as an attack on Rexx; I interpreted them as statements made in error. I was attempting to correct those; and not to attack either you or TCL. And I didn't post twice to make the point even harsher - that was a stupid mistake. >> REXX syntax and structure is based on that of PL/I, which is fine. Rexx also has better simple string handling capabilities than TCL. Rexx has string operators as part of the basic language, TCL has "string match" & "format", giving it a lot more power than than raw Rexx. > 2) "ARexx requires the programmer to provide a scripting language." OK, Arexx requires the programmer to provide a command line interpreter. String parser of some kind, which for most applications will be a command line interpreter. Look at treewalk & RexxPlPlot for counterexamples, though. TCL is a fine command line interpreter. REXX -- meet TCL. TCL -- meet REXX. From the looks of things, it should be straightforward to build a TCL/Rexx package that allows one to send Rexx messages to hosts from a TCL program, and to process Rexx messages in TCL. Since TCL (at least, the docs in the copy I have say this) doesn't yet have IP, there's not much point in doing the opposite. However, what get's passed to a TCL "client" command looks an awful lot like a Rexx RXFUNC message. Following through on that to make the AmigaTCL IP use Rexx messages would give TCL isntant access to RexxArpLib & the like. Such facilities may already be in AmigaTCL, though... What's interesting is that the two languages were meant for such similar applications, and it shows - yet they are such different languages. Rexx has stemmed variables (associative, multi-level arrays), and strings that can be processed along the lines of a TCL list. TCL does real lists & pointers instead. Both have a way of evaluating strings as expressions. TCL does C-like strings, with some extra magic for dealing with filenames. Rexx is more a mini-snobol for strings. Both have a way of accessing variables from calling environments (and neither shows it at the point of the call - bleah). That the two languages are radically different means different applications would be better off with one or another - or maybe even both (especially if MinRexx & Tcl_CreateCommand can be convinced to use the same data struture). It'd be nice to have a collection of programs that had both interfaces - or were available with both, just to play with the two. Someone want to post a version of FreeDraw with a TCL interface, and samples to duplicat Tomas's Rexx scripts? That'd be a good start. Treewalk, Nag, an emacs-like editor & fiveinline with TCL hooks (ok, I haven't released the Rexx-ported version yet) would also be nice to see. <mike -- Round about, round about, in a fair ring-a. Mike Meyer Thus we dance, thus we dance, and thus we sing-a. mwm@relay.pa.dec.com Trip and go, to and fro, over this green-a. decwrl!mwm All about, in and out, over this green-a.
peter@sugar.hackercorp.com (Peter da Silva) (03/04/90)
> 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?" `-_-'
papa@pollux.usc.edu (Marco Papa) (03/04/90)
One drawback I see at the moment of Tcl vs. Arexx on the Amiga is that the former one is not made into a .library. As such, an unreasonable duplication of code would result when multiple programs use it (which is what one would want to do). While this duplication is uninportant in virtual-memory systems like UNIX, it can be a BIG drawback on systems like the Amiga. Currently Arexx runs a single version of the interpreter plus a number of libraries. Are you guys at hackercorp working on a Tcl library? -- Marco -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= "Xerox sues somebody for copying?" -- David Letterman -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
limonce@pilot.njin.net (Tom Limoncelli) (03/04/90)
In article <48f6cbee.db93@edsel.engin.umich.edu> chrisl@caen.engin.umich.edu (Chris Lang) writes: > I'm not sure what that means. True, with ARexx the developer needs to write > code to handle all the commands the application can receive from an ARexx > script/program, but this hardly the same as writing an entire scripting > language, is it? How will Tcl change this...won't one still need to write ^^^^^^^^^^^^^^^^^^^^^^^^^ > the code to handle any commands it can receive? (True, you won't need to No, you tell Tcl what the token is, where the code for it's handler starts, and it does everything. -- 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
peter@sugar.hackercorp.com (Peter da Silva) (03/05/90)
> Following through on that to make the AmigaTCL IP use Rexx messages > would give TCL isntant access to RexxArpLib & the like. Such > facilities may already be in AmigaTCL, though... Yes, since the TCL command is already built up of a simply structured list of strings, it's kind of silly to package them into a string and pull them apart again at the other end. -- _--_|\ 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?" `-_-'
bdb@becker.UUCP (Bruce Becker) (03/05/90)
In article <5230@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: |Hey man, your mission is getting UNIX emulation under AmigaOS. Don't sweat |the small stuff... And REXX up & running under UNIX... (OK, Mr. H.??? 8^) -- (__) Bruce Becker Toronto, Ontario w \@@/ Internet: bdb@becker.UUCP, bruce@gpu.utcs.toronto.edu `/v/-e UUCP: ...!uunet!mnetor!becker!bdb _/ \_ "They never tell you shit like this in high school!" - J. R. Dobbs
mwm@raven.pa.dec.com (Mike (Real Amiga have keyboard garages) Meyer) (03/06/90)
In article <5241@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: > Following through on that to make the AmigaTCL IP use Rexx messages > would give TCL isntant access to RexxArpLib & the like. Such > facilities may already be in AmigaTCL, though... Yes, since the TCL command is already built up of a simply structured list of strings, it's kind of silly to package them into a string and pull them apart again at the other end. That's why I said use RXFUNC messages. If you look at Rexx messages, you'll notice they have an array of pointers to characters imbedded in them (sound familiar?). When sending RXCOMM (what you're thinking of) messages, all but the first one are ignored. However, when you send RXFUNC messages, the first one contains the name of the script (SOP), and the others contain pointers to argument strings. You can safely treat the strings on the recieving end as C strings. You can pass C strings, but it's safer to call CreateRexxArg (or somesuch - I don't have the docs here) to generate doped strings that will be correctly dealt with by ClearRexxMsg (ditto). In other words, the (fast & sloppy) TCL command to send a Rexx message would look like (done sans manuals, so don't quote me): int SendToRexx(ClientData data, Tcl_Interp *interp, int argc, char *argv[]) { struct RexxMsg *msg ; int out ; if (argc > 14) return TCL_ERROR ; /* Limit of ARexx */ msg = CreateRexxMsg(...) ; for (i = 0; i < argc; i++) msg->Rm_Arg[i] = argv[i] ; SendRexxMsg(msg) ; out = msg->rm_Result1 ; DeleteRexxMsg(msg) ; return out ; } I do similar things in mg3a to allow the user to run a region as a function and insert the result back into the buffer. Makes for some interesting possibilities. <mike -- When logic and proportion have fallen softly dead, Mike Meyer And the white knight is talking backwards, mwm@relay.pa.dec.com And the red queen's off her head, decwrl!mwm Remember what the dormouse said.
tell@oscar.cs.unc.edu (Stephen Tell) (03/06/90)
In article <1990Mar3.032234.12351@haven.umd.edu> louie@sayshell.umd.edu (Louis A. Mamakos) writes: >What I'd really like is an implementation of PERL as a scripting language >and tool for the Amiga. There was a port of PERL version 1.x a few years >back; an AREXX like IPC interface to a PERL interpreter with all of its >regex stuff would be really fun.. YES!YES!YES!YES!YES!YES! I just bought AREXX and started playing with it, and I love that IPC, but find the language itself rather primitive compared to Perl. It may just be that I haven't gotten enough into it, but I would like to use just one language everywhere. Perl might need extensive work to make it mostly a resident library and re-entrant process like REXX; otherwise it would hog too much memory for each running script. The Amiga Perl 1 binary was somthing like 100K. This will probably be the hardest part; I looked the other port and it was nice and clean; very few amiga-specifics. I forget who did it, but I still use it. I see somthing like extending the 'do' (subroutine call) keyword with the capabilities of Arexx's Address command. Of course the IPC would be AREXX compatible. Maybe when I save up the $ for a 2000HD I'll tackle it. Lets get all the languages out there, and may the best one win. Of course what's best for one job may not be best for another. Love them regular expressions, though. -------------------------------------------------------------------- Steve Tell tell@wsmail.cs.unc.edu CS Grad Student, UNC Chapel Hill. "Yet another Perl hacker." Former chief engineer, Duke Union Community Television, Durham, NC.
chrisl@caen.engin.umich.edu (Chris Lang) (03/06/90)
In article <Mar.4.00.37.35.1990.19269@pilot.njin.net> limonce@pilot.njin.net (Tom Limoncelli) writes: >In article <48f6cbee.db93@edsel.engin.umich.edu> chrisl@caen.engin.umich.edu (Chris Lang) writes: >> language, is it? How will Tcl change this...won't one still need to write > ^^^^^^^^^^^^^^^^^^^^^^^^^ >> the code to handle any commands it can receive? (True, you won't need to > >No, you tell Tcl what the token is, where the code for it's handler >starts, and it does everything. But you still need to write the handler yo'self, right? This is what I was getting at, although in an admittedly unclear fashion. I realize Tcl will take care of the parsing and so on for me. (In other words, we're talking about the difference between having a startup.o to parse my application's command line, and having to do it myself, only for scripts, right?) -Chris ----- Chris Lang University of Michigan, College of Engineering home: 4622 Bursley work: National Center for Manufacturing Sciences Ann Arbor, MI 48109 900 Victors Way, Suite 226 (313) 763-1832 Ann Arbor, MI 48108 chrisl@caen.engin.umich.edu (313) 995-0300 "I hate quotations. Tell me what you know." - Ralph Waldo Emerson
deven@rpi.edu (Deven T. Corzine) (03/07/90)
On 2 Mar 90 12:44:21 GMT, peter@sugar.hackercorp.com (Peter da Silva) said: Peter> Hey man, your mission is getting UNIX emulation under AmigaOS. Peter> Don't sweat the small stuff... Well, yeah... but tcl is _real_ neat. :-) Deven [yes, I'm easily distracted. Ah, well.] -- Deven T. Corzine Internet: deven@rpi.edu, shadow@pawl.rpi.edu Snail: 2151 12th St. Apt. 4, Troy, NY 12180 Phone: (518) 274-0327 Bitnet: deven@rpitsmts, userfxb6@rpitsmts UUCP: uunet!rpi!deven Simple things should be simple and complex things should be possible.
deven@rpi.edu (Deven T. Corzine) (03/07/90)
On 4 Mar 90 03:10:55 GMT, papa@pollux.usc.edu (Marco Papa) said: Marco> One drawback I see at the moment of Tcl vs. Arexx on the Amiga Marco> is that the former one is not made into a .library. As such, an Marco> unreasonable duplication of code would result when multiple Marco> programs use it (which is what one would want to do). While Marco> this duplication is uninportant in virtual-memory systems like Marco> UNIX, it can be a BIG drawback on systems like the Amiga. Marco> Currently Arexx runs a single version of the interpreter plus a Marco> number of libraries. Are you guys at hackercorp working on a Marco> Tcl library? This was my firm intention when I decided that I wanted to port Tcl. I odn't know about the guys at hackercorp, but that was my plan. Tcl is SO well suited a candidate for a shared library -- it was written with that in mind. Marco, if you plan to use Tcl w/Atalk III, might I suggest that you wait for a tcl.library, use that (and include it with Atalk if you can) and just do simple parsing instead of failing if tcl.library isn't there... Peter, Karl -- was either of you at Usenix? Damn. I really wish I woke up early enough to catch the Tcl talk. I was at Usenix, but I missed the talk on Tcl. But I do have the conference proceedings, and I've read the (excellent) paper. And I did catch a lot of the excitement floating around from Tcl... It's a Good Thing (tm). As for Tcl vs. ARexx, the simple answer is, Tcl gives you a lot that ARexx doesn't. The not so simple answer? I haven't the time to go into it. The Tcl paper is highly recommended reading. For anyone using or interested in using Tcl on a Sun, I did the extra work necessary to create a shared tcl library under SunOS 4.0 -- email me if you want the Makefile. (I expect I'll send it to the author if he's interested.) Deven -- Deven T. Corzine Internet: deven@rpi.edu, shadow@pawl.rpi.edu Snail: 2151 12th St. Apt. 4, Troy, NY 12180 Phone: (518) 274-0327 Bitnet: deven@rpitsmts, userfxb6@rpitsmts UUCP: uunet!rpi!deven Simple things should be simple and complex things should be possible.
peter@sugar.hackercorp.com (Peter da Silva) (03/07/90)
> Peter, Karl -- was either of you at Usenix? No, my boss (Randy Kunkee) was, but what with one thing and another we didn't get to go. He brought back the technical papers, though, and that included the one on TCL. I wish I'd gotten to the talk... just reading the paper was pretty exciting. > For anyone using or interested in using Tcl on a Sun, I did the extra > work necessary to create a shared tcl library under SunOS 4.0 -- email > me if you want the Makefile. (I expect I'll send it to the author if > he's interested.) I suspect he will be... he's been pretty prompt about responding to my mail. -- _--_|\ 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?" `-_-'
karl@sugar.hackercorp.com (Karl Lehenbauer) (03/08/90)
In article <23217@usc.edu> papa@pollux.usc.edu (Marco Papa) writes: >One drawback I see at the moment of Tcl vs. Arexx on the Amiga is that the >former one is not made into a .library. >Are you guys at hackercorp working on a Tcl library? Yes. Manx 5.0 greatly simplifies the creation of libraries. You create a .fd file and the mapfd program, which comes with 5.0, generates the amicall pragmas for the library. You use the -qp compiler option to generate the function prototypes. Then a bit of monkey business and magic (a sample shared library, with source, that actually compiles and works is included in 5.0) and you have a shared library. I have done almost all of the work necessary to make Tcl and my Tcla Amiga extension for interprocess communications, windows, menus, gadgets, fonts, drawing and event loop handling into a shared library. This mainly involved moving all global data into ClientData structures associated with the Tcla extensions. Fortunately, vanilla Tcl keeps all of its data in or subordinate to Tcl_Interp data structures, so Tcl itself requires hardly any diddling to make it work within a shared lib. I haven't finished the job because I like calling printf and such when I'm debugging, and doing so from a shared library introduces some difficulties. I may have to have the user of the shared library pass pointers to some functions up to the shared library, that the library can then call the user-specified functions when it needs to, functions like write and panic. -- -- uunet!sugar!karl "As long as there is a legion of superheros, all else -- can surely be made right." -- Sensor Girl -- Usenet access: (713) 438-5018
hopp@agnes.acc.stolaf.edu (Eric D. Hopp) (03/10/90)
In article <5237@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: >> (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. Amen! That is one thing that has really bugged me about UNIX. UNIX commands tend to use single character flags, which is fine, but they rarely have a consistent meaning between any two commands, which is really confusing. TAR comes to mind as one that I always have to read the man page before I use it. "r" is the flag for writing, and "t" for listing??? To paraphrase what Apple says about the Macintosh user interface, "All programs should interface with the user in similar, consistent manners, so that the users will know what to expect." The Amiga Intuition manual echos this, as have a lot of frustrated users I've known. I think it's an excellent rule of thumb; users will be able to learn your software that much more easily. This is especially useful to anyone who agrees with UNIX's philosophy of having many small tools, each doing it's one thing and doing it well, which can be glued at a whim into larger, more useful applications. Pipes are not that great, but from what I hear ARexx comes much closer. Consistent interfaces (via TCL or another agent) will make life easier for everyone, and will make ARexx that much more popular. Peter da Silva's suggestion that programs with ARexx ports each support a consistant syntax is right on! -eric hopp hopp@stolaf.edu