From mboxrd@z Thu Jan 1 00:00:00 1970 From: erik quanstrom Date: Tue, 28 Aug 2012 16:34:10 -0400 To: crossd@gmail.com, 9fans@9fans.net Message-ID: <8ee568439e1855124564ecf0e83ac2b3@kw.quanstro.net> In-Reply-To: References: <68ce90976b22bdb0929ccccafef4b7d0@kw.quanstro.net> <3330200.XJjoRb8JbZ@blitz> <5538fcd345a73fc294c6ee568f2fcdb4@kw.quanstro.net> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [9fans] rc's shortcomings (new subject line) Topicbox-Message-UUID: b21e3614-ead7-11e9-9d60-3106f5b1d025 > > the haahr/rakitzis es' if makes more sense, even if it's wierder.) >=20 > Agreed; es would be an interesting starting point for a new shell. es is great input. there are really cool ideas there, but it does seem like a lesson learned to me, rather than a starting point. > I think in order to really answer that question, one would have to > step back for a moment and really think about what one wants out of a > shell. There seems to be a natural conflict a programming language > and a command interpreter (e.g., the 'if' vs. 'if not' thing). On > which side does one err? since the raison d'=C3=AAtre of a shell is to be a command interpter, i'd go with that. > I tend to agree. As a command interpreter, rc is more or less fine as > is. I'd really only feel motivated to change whatever people felt > were common nits, and there are fairly few of those. there are nits of omission, and those can be fixable. ($x(n-m) was added= ) > > perhaps (let's hope) someone else has better ideas. >=20 > Well, something off the top of my head: Unix pipelines are sort of > like chains of coroutines. And they work great for defining linear > combinations of filters. But something that may be interesting would > be the ability to allow the stream of computations to branch; instead > of pipelines being just a list, make them a tree, or even some kind of > dag (if one allows for the possibility of recombining streams). That > would be kind of an interesting thing to play with in a shell > language; I don't know how practically useful it would be, though. rc already has non-linear pipelines. but they're not very convienient. i think part of the problem is answering the question, what problem would we like to solve. because "a better shell" just isn't well-defined enough. 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. but it would be okay for almost every use of this if *.[ch] were generate= d in parallel with any number of grep's being run. i suppose i'm stepping close to sawzall now. - erik