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

[Dan Cross <crossd@gmail.com>]

On Tue, Aug 28, 2012 at 8:56 PM, erik quanstrom <quanstro@quanstro.net> 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—just ugly.

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=() y=() cmd
>
> cmd can be a function body or whatever.  x and y are then private
> to cmd.  you can nest redefinitions.
>
>         x=1 y=2 {echo first $x $y; x=a y=b {echo second $x $y; x=α y=β {echo third $x $y}; echo ret second $x $y}; echo ret first $x $y}
>         first 1 2
>         second a b
>         third α β
>         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.