[REBOL] Re: REBOL Cookbook in Beta
From: mmastroianni:lepcorp at: 2-Sep-2003 18:06
Hi Gregg,
Well, I think the thing is this: unless
you're using REBOL/Command (and maybe even
if you *are*), it's a bit tricky to pipe
the output of one rebol program into another,
and into another, etc., in true *nix style:
ls *.txt | tail +10 | sort > pipe.result
The reason in practice is that there are lots
of oddball interactions that manifest themselves
in specific shell environments, in my experience.
We use Windows XP here a lot, calling REBOL programs
from command shell scripts, but I also use a Bash-like
shell from Thompson Toolkit, and folks use products like
MKS Toolkit under Windows to get a *nix-like environment
as well. (Even Microsoft provides a *nix environment
set of utilities - I just got a sample CD in the mail.)
I imagine REBOL is better behaved in this regard
under Linux, but I think the cross-platform benefit
of a standard paradigm that is elegant and works
would be far better, in retrospect.
That said, aside from well-designed functions
that work well together, or maybe the OO stuff
that I don't fully appreciate yet in REBOL,
what *is* that paradigm or structure that would
provide the clean utility of a pipe ? Perhaps
this is best implemented as an enhancement to REBOL,
as I believe the idea of a pipe is *very* elegant
and conducive to problem-solving in a way
that is very light and natural to understand.
Maybe the way ports are implemented in REBOL would
provide a means to implement pipe-like functionality.
When you break it down, REBOL *has* all the "stuff"
that you need to take data, transform it, transform it
again, and again, etc., ad nauseum until you get the
desired result. The problem for me is that instead
of seeing a clear linear flow of data transformations
that a pipe approach reveals, you end up with nested
transformations that might tend to obscure what you're
trying to accomplish. I.e., sort of the difference
between the following ideas
a < data | b | c | d | e | f > outfile
and
write f(e(d(c(b(a(data))))))
I prefer the first for clarity, given my experiences
with the pipe idea.
There was also something I heard IBM folks raving about
a while back about the elegance and utility of "named pipes",
which may also be a productive thing to look at.
Not sure if this is helpful in the way you'd hoped...
Mike
