From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <5538fcd345a73fc294c6ee568f2fcdb4@kw.quanstro.net> References: <68ce90976b22bdb0929ccccafef4b7d0@kw.quanstro.net> <3330200.XJjoRb8JbZ@blitz> <5538fcd345a73fc294c6ee568f2fcdb4@kw.quanstro.net> From: Dan Cross Date: Wed, 29 Aug 2012 01:11:26 +0530 Message-ID: To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [9fans] rc's shortcomings (new subject line) Topicbox-Message-UUID: b1d6bd16-ead7-11e9-9d60-3106f5b1d025 On Tue, Aug 28, 2012 at 8:56 PM, erik quanstrom wro= te: >> And rc is not perfect. I've always felt like the 'if not' stuff was a k= ludge. > > no, it's certainly not. (i wouldn't call if not a kludge=E2=80=94just ug= ly. 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. > the haahr/rakitzis es' if makes more sense, even if it's wierder.) Agreed; es would be an interesting starting point for a new shell. > but the real question with rc is, what would you fix? 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? > 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. 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. > perhaps (let's hope) someone else has better ideas. 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. >> 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. (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.) > 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 ret f= irst $x $y} > first 1 2 > second a b > third =CE=B1 =CE=B2 > ret second a b > ret first 1 2 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. > 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. 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. - Dan C.