Re: [9fans] rc's shortcomings (new subject line)

[Dan Cross <crossd@gmail.com>]

On Thu, Aug 30, 2012 at 7:03 PM, erik quanstrom <quanstro@quanstro.net> wrote:
>> rejected such system-imposing structure on files in Unix-y type
>> environments since 1969.
> [...]
>> other threads of execution.  Could we do something similar with pipes?
>>  I don't know that anyone wants typed file descriptors; that would
>> open a whole new can of worms.
>
> i don't see that the os can really help here.  lib9p has no problem
> turning an undelimited byte stream → 9p messages.  there's no reason
> any other format couldn't get the same treatment.

Yeah, I don't see much here unless one breaks the untyped stream model
(from the perspective of the system).

> said another way, we already have typed streams, but they're not
> enforced by the operating system.

Yes, but then every program that participates in one of these
computation networks has to have that type knowledge baked in.  The
Plan 9/Unix model seems to preclude a general mechanism.

> one can also use the thread library technique, using shared memory.

Sure, but that doesn't do much for designing a new shell.  :-)

>> Consider a simple reduction in Lisp; say, summing up a list of numbers
>> or something like that.  In Common Lisp, we may write this as:
>>
>>     (reduce #'+ '(1 2 3 4 5))
>>
>> In clojure, the same thing would be written as:
>>
>>     (reduce + [1 2 3 4 5])
>>
>
> this reminds me of a bit of /bin/man.  it seemed that the case statement
> to generate a pipeline of formatting commands was awkward—verbose
> and yet limited.
>
>         fn pipeline{
>                 if(~ $#* 0)
>                         troff $Nflag $Lflag -$MAN | $postproc
>                 if not{
>                         p = $1; shift
>                         $p | pipeline $*
>                 }
>         }
>
>         fn roff {
>                 ...
>                 fontdoc $2 | pipeline $preproc
>         }

Ha!  That's something.  I'm not sure what, but definitely something (I
actually kind of like it).

>> http://clojure.com/blog/2012/05/08/reducers-a-library-and-model-for-collection-processing.html
>>
>> Your example of running multiple 'grep's in parallel sort of reminded
>> me of this, though it occurs to me that this can probably be done with
>> a command: a sort of 'parallel apply' thing that can run a command
>> multiple times concurrently, each invocation on a range of the
>> arguments.  But making it simple and elegant is likely to be tricky.
>
> actually, unless i misread (i need more coffee), the blog sounds just like
> xargs.

Hmm, not exactly.  xargs would be like reducers if xargs somehow asked
stdin to apply a program to itself.

A parallel apply sort of thing could be used with xargs, of course;
'whatever | xargs papply foo' could keep some $n$ of foo's running at
the same time.  The magic behind 'papply foo `{whatever}' is that it
knows how to interpret its arguments in blocks.  xargs will invoke a
command after reading $n$ arguments, but that's mainly to keep from
overflowing the argument buffer, and (to my knowledge) it won't try to
keep multiple instances running them in parallel.

Hmm, I'm afraid I'm off in the realm of thinking out loud at this
point.  Sorry if that's noisy for folks.

        - Dan C.