> > 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.
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'être 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.
>
> 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 generated
in parallel with any number of grep's being run.
i suppose i'm stepping close to sawzall now.
- erik
