From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <50463A08.7050204@gmail.com> Date: Tue, 4 Sep 2012 19:27:36 +0200 From: =?UTF-8?B?8J+YnA==?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120902 Thunderbird/15.0 MIME-Version: 1.0 To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> References: <68ce90976b22bdb0929ccccafef4b7d0@kw.quanstro.net> <3330200.XJjoRb8JbZ@blitz> <5538fcd345a73fc294c6ee568f2fcdb4@kw.quanstro.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [9fans] rc's shortcomings (new subject line) Topicbox-Message-UUID: b6c09f90-ead7-11e9-9d60-3106f5b1d025 Hi, just my 2=C2=A2 for the fanning out of pipes: if I remember correctly= , mycroftiv's hubfs (or some other software in his contrib) allowed one to do exactly this. hth On 08/28/2012 09:41 PM, Dan Cross wrote: > On Tue, Aug 28, 2012 at 8:56 PM, erik quanstrom = wrote: >>> And rc is not perfect. I've always felt like the 'if not' stuff was = a kludge. >> >> no, it's certainly not. (i wouldn't call if not a kludge=E2=80=94just= ugly. >=20 > Kludge perhaps in the sense that it seems to be to work around an > issue with the grammar and the expectation that it's mostly going to > be used interactively, as opposed to programmatically. See below. >=20 >> 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. >=20 >> but the real question with rc is, what would you fix? >=20 > 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? >=20 >> i can only think of a few things around the edges. `{} and $ are >> obvious and is some way to use standard regular expressions. but >> those really aren't that motivating. rc does enough. >=20 > 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. >=20 >> 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. >=20 >>> switch/case would make helluva difference over nested if/if not, if >>> defaulted to fall-through. >> >> maybe you have an example? because i don't see that. if not works >> fine, and can be nested. case without fallthrough is also generally >> what i want. if not, i can make the common stuff a function. >> >>> variable scoping (better than subshel) would help writing larger >>> scripts, but that's not necessarily an improvement ;-) something >>> similar to LISP's `let' special form, for dynamic binding. >=20 > (A nit: 'let' actually introduces lexical scoping in most Lisp > variants; yes, doing (let ((a 1)) ...) has non-lexical effect if 'a' > is a dynamic variable in Common Lisp, but (let) doesn't itself > introduce dynamic variables. Emacs Lisp is a notable exception in > this regard.) >=20 >> there is variable scoping. you can write >> >> x=3D() y=3D() cmd >> >> cmd can be a function body or whatever. x and y are then private >> to cmd. you can nest redefinitions. >> >> x=3D1 y=3D2 {echo first $x $y; x=3Da y=3Db {echo second $x $y;= x=3D=CE=B1 y=3D=CE=B2 {echo third $x $y}; echo ret second $x $y}; echo r= et first $x $y} >> first 1 2 >> second a b >> third =CE=B1 =CE=B2 >> ret second a b >> ret first 1 2 >=20 > This syntax feels clunky and unfamiliar to me; rc resembles block > scoped languages like C; I'd rather have a 'local' or similar keyword > to introduce a variable in the scope of each '{ }' block. >=20 >> you should try the es shell. es had let and some other scheme-y >> features. let allows one to do all kinds of tricky stuff, like build >> a shell debugger in the shell, but my opinion is that es was more >> powerful and fun, but it didn't buy enough because it didn't really >> expand on the essential nature of a shell. what can one do to >> manipulate processes and file descriptors. >=20 > es was a weird merger between rc's syntax and functional programming > concepts. It's neat-ish, but unless we're really ready to go to the > pipe monad (not that weird, in my opinion) you're right. Still, if it > allowed one to lexically bind a file descriptor to a variable, I could > see that being neat; could I have a closure over a file descriptor? I > don't think the underlying process model is really set up for it, but > it would be kind of cool: one could have different commands consuming > part of a stream in a very flexible way. >=20 > - Dan C. >=20