Re: [9fans] typed sh (was: what features would you like in a shell?)

[Bakul Shah <bakul+plan9@bitblocks.com>]

On Mon, 06 Apr 2009 07:09:47 EDT erik quanstrom <quanstro@quanstro.net>  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 are compatable
> at all; that's the beauty of pipes.

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".  Even for programs like wc have a concept of a
'character' and if the prev prog. produces something else you
will be counting something meaningless.

Perhaps it is impossible to capture such type compatibility
in anything but runtime IO routines but the concept exists.

>                                      you can do things
> that were not envisioned at the time the programs were
> written.

That comes from composability.

> > To go beyond simple char streams, one can for example build a
> > s-expr pipeline: a stream of self identifying objects of a
> > few types (chars, numbers, symbols, lists, vectors). In Q
> > (from kx.com) over an IPC connection you can send strings,
> > vectors, dictionaries, tables, or arbitray Q expressions. But
> > there the model is more of a client/server.
>
> or ntfs where files are databases.  not sure if streams
> can look the same way.

May be not.  What I was getting at was that one can do a lot
with a small number of IO types -- no need for "type
profligacy"!  [Unless your definition of profligacy is
anything more than one.]  The nice thing about s-expr is that
you have a syntax for structured IO and its printer, parser
are already written for you.  Anyway, a typed sh would be an
interesting experiment.