From mboxrd@z Thu Jan 1 00:00:00 1970 From: erik quanstrom Date: Tue, 28 Aug 2012 21:28:07 -0400 To: 9fans@9fans.net Message-ID: <1f827ad670e52e0e6f23ebdd9c6a0c00@brasstown.quanstro.net> In-Reply-To: <20120828224632.547BAB827@mail.bitblocks.com> References: <68ce90976b22bdb0929ccccafef4b7d0@kw.quanstro.net> <3330200.XJjoRb8JbZ@blitz> <5538fcd345a73fc294c6ee568f2fcdb4@kw.quanstro.net> <8ee568439e1855124564ecf0e83ac2b3@kw.quanstro.net> <20120828224632.547BAB827@mail.bitblocks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] rc's shortcomings (new subject line) Topicbox-Message-UUID: b2f1425c-ead7-11e9-9d60-3106f5b1d025 > On Tue, 28 Aug 2012 16:34:10 EDT erik quanstrom wrote: > > my knee-jerk reaction to my own question is that making it easier > > and more natural to parallelize dataflow. a pipeline is just a really > > low-level way to talk about it. the standard > > grep x *.[ch] > > forces all the *.[ch] to be generated before 1 instance of grep runs on > > whatever *.[ch] evaluates to be. > > Here the shell would have to understand program behavior. > Consider something like > > 8l x.8 y.8 z.8 ... > > This can't be parallelized (but a parallelizable loader can be > written). ya, ya. improving on rc in a noticable way is hard. and thinking aloud is a bad idea. and a good way to look foolish. - erik