On Fri, Mar 20, 2009 at 10:41 AM, Boyko Bantchev <[email protected]> wrote:
> I did not include the Unix family of sh-like languages, because
> they cannot be used the way REXX can be, and is being used.
> REXX comes with an API, through which one can call script chunks
> from within a compiled program and pass data between the script
> and the program.
Well... where explicit support of certain coroutine functionality
is critical, then I agree that rexx scripts can be cleaner than
shell scripts. However, I am reluctant to equate a specific
coroutine implementation with "o.s. command (shell) language,
and a system-scripting-and-integration language"
Also, anything sort of integration work you can do with
coroutines you can also do without coroutines: Any data
which needs to be passed can be passed in files. And
processing which needs to occur can occur in newly spawned
processes. If this is a problem then it is a problem introduced
by the os.
Also, you can use pipes (named or not), when they are
convenient. In many cases this is good enough.
> Also, most Unix shells are not full-featured languages (lacking,
> e.g., f.p. arithmetic). REXX is.
Shell scripts routinely delegate such tasks to spawned
processes, and /bin/sh has rich support for spawning
various kinds of processes. For example,
:|awk 'END{print 1.2+2.3}'
3.5
This of course is crude, but /bin/sh was designed
to integrate a system with a standard set of system
utilities available for its use. This seems to me to
be a good design in the context of a systems
integration language.
--
Raul
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
