Re: everyone's least favorite creatures

[haahr@mv.us.adobe.com (Paul Haahr)]

> > i'll admit up front that i'll probably reply to a good number of
> > good suggestions with ``NO! we NEED that!''

> `Needing' something isn't a reason to put it in initial.es if it can
> by synthesized from primitive stuff.  It's a reason to have a custom
> environment full of things you need.

that's not what i meant by needing.  what i meant, and i can see how
it might have been hard to figure this out from what i said, was that
there are a number of features which appear to be completely gratuitous,
but which we needed to implement some of the required functionality of
the shell.

for example, %fsplit is not really necessary as a shell feature.
on the other hand, we needed it in order to do path/PATH and
cdpath/CDPATH aliasing at ``user'' level.  does that make it
a creeping feature?

now, what is ``required functionality of the shell''?  that's somewhat
vague, but, personally, i consider it equivalent shell-like functionality
to rc.  that is, all of the redirections, pipes, backgrounding, ||, &&,
path searching, the environment, etc.  in cases, es has gone further
towards matching traditional shells than rc (e.g., ~user expansion) and in
cases it does less (e.g., exec {>foo} instead of exec > foo).

> You might consider the dumping (or encapsulation) of the environment
> to be a meta-need for satisfying needs.

i think that Noah's package stuff (and to a lesser extent, the autoloading
hack in the sample .esrc) go a long way to addressing this need.

on a related note, we keep hearing suggestions about dynamic loading of
c code, but are hesitant to make it an official part of es, for a number
of reasons, including

	+ portability across unix versions is hard (though not impossible).
	  note that this is the reason that Ousterhout gives for tcl not
	  supporting dynamic linking, and, imho, tcl is a much better
	  candidate for dynamic linking than es, at least in its current
	  implementation.

	+ the details of writing es primitives (i.e., c code that works
	  with es) is constantly changing.  there will be a rev in the
	  next major release to support lexical scoping of function names,
	  for example.

paul