On Thu, 16 Apr 2009 18:24:36 BST roger peppe wrote:
> 2009/4/6 Bakul Shah :
> > On Thu, 02 Apr 2009 20:28:57 BST roger peppe =C2=A0w=
> rote:
> >> a pipeline is an amazingly powerful thing considering
> >> that it's not a turing-complete abstraction.
> >
> > "f | g" is basically function composi
2009/4/6 Bakul Shah :
> On Thu, 02 Apr 2009 20:28:57 BST roger peppe wrote:
>> a pipeline is an amazingly powerful thing considering
>> that it's not a turing-complete abstraction.
>
> "f | g" is basically function composition, where f and g are
> stream functions. Of course, this simple analogy
> but forcing compability seems worse. where are these decisions
> centralized? how do you change decisions? can you override
> these decisions (cast)? how does the output of, say, awk get
> typed?
The output of awk is a byte stream, same as its input. The
same holds for any program. If you
> > but rather that using text streams makes
> > A|B possible for any A and any B and any input.
> What is this "text" of which you speak ? ASCII EBCDIC UTF-16 UTF-8
> ISO8859 etc. etc. etc.
there's got to be a latin term parallel to reducto ad absurdum that
means the opposite. make the proble
On Mon, 06 Apr 2009 12:02:21 EDT erik quanstrom wrote:
> > If program A outputs numbers in big-endian order and B
> > expects input in little-endian order, A|B won't do the "right
> > thing".
>
> non-marshaled data considered harmful. film at 11. âº
In effect you are imposing a constraint
but rather that using text streams makes
A|B possible for any A and any B and any input.
What is this "text" of which you speak ? ASCII EBCDIC UTF-16 UTF-8
ISO8859 etc. etc. etc.
> If program A outputs numbers in big-endian order and B
> expects input in little-endian order, A|B won't do the "right
> thing".
non-marshaled data considered harmful. film at 11. ☺
what i said was not that A|B "makes sense" for all A and B
and for any data but rather that using text stream
On Mon, 06 Apr 2009 07:09:47 EDT erik quanstrom wrote:
> > Nitpick: the output type of one command and the input type of
> > the next command in the pipeline has to match, not every
> > command.
>
> i think this is wrong. there's no requirement
> that the programs participating in a pipeline ar
> Nitpick: the output type of one command and the input type of
> the next command in the pipeline has to match, not every
> command.
i think this is wrong. there's no requirement
that the programs participating in a pipeline are compatable
at all; that's the beauty of pipes. you can do things
t
On Thu, 02 Apr 2009 20:28:57 BST roger peppe wrote:
> 2009/4/2 :
> i wanted to go a little beyond sh while stopping
> short of the type profligacy of most other languages,
> hoping to create a situation where many commands
> used exactly the same types, and hence were
> viable to pipeline togeth
I don't know if others have already hit this kind of problematic, but I
was dealing with a fair amount of C code, usable both as a library and
accessible by a shell. Plus debugging needs. So I was, again and again,
writing a wrapper to access a C function from the shell.
So I ended concluding that
2009/4/2 :
> On Thu, Apr 2, 2009 at 8:41 PM, John Stalker wrote:
>> What I most often miss in shell programming is a proper type system.
> You should have a look at alphabet. It is cool.
> http://www.vitanuova.com/inferno/man/1/sh-alphabet.html
i certainly enjoyed creating it. unfortunately it's
On Thu, Apr 2, 2009 at 8:41 PM, John Stalker wrote:
> What I most often miss in shell programming is a proper type system.
You should have a look at alphabet. It is cool.
http://www.vitanuova.com/inferno/man/1/sh-alphabet.html
13 matches
Mail list logo
