Re: everyone's least favorite creatures

[peter@robots.oxford.ac.uk]

> Noah wrote, a long time ago
> > >what features of the language would you (everyone on the list) remove?
> 
> > 1) `%cdpathsearch', `%is-absolute', and the version of `cd' which use them.
> >    Related things that can be eliminated are `set-cdpath', `set-CDPATH',
> >    and the `cdpath' variable.
> 
> i don't agree, but i could be convinced.  what do other people think.
> my first reaction was to keep these in the shell for cultural compatibility
> with other shells.

I think we have to think about general users as well, so having cultural
compatibility at this basic level is necessary.  Although I think having a
special %is-absolute is unnecessary, just make it explicit.

> > 2) The `apids', `var', `vars', and `whatis' commands.
>
> apids, var:  these two are not that important.  should they disappear?
> (note that %apids and %var would stay.)

I think once you've spent some time using es, you get used to typing echo
<=cmd, it even becomes a real pleasure :-), so remove the echo <={} versions.

> >    I notice that %background seems to maintain a variable `apid' which may
> >    in fact be different from what $&apids returns.  I suggest one or the
> >    other be eliminated.
> 
> this is for compatibility with rc.  ($apid is exactly the same as rc's
> $apid, where ``apids'' is the same as rc's ``echo $apids'')  i don't
> do stuff in the background very often, so i use these just about never.

I use ``&'' a lot, having the pid echoed and saved is a very useful
interactive feature, I'm also glad that I can use $&background to override
it too.  I'd like to retain it because I like to monitor the background job
once in while with ``ps aux$apid''.  Cultural compatibility is important
here as Paul said.

> > 3) Why are `true' and `false' primitives?  Aren't
> >         fn true { result 0 }
> >         fn false { result 1 }
> >    good enough?  Maybe we don't really need them at all, in fact, since you
> >    could just use {result 0} or {result 1} explicitly in place of them.
> 
> i think they shouldn't be primitives, but should still be built into the
> language.  $&true and $&false are leaving the language soon.

I use true and false a lot, it documents the scripts better than 0 and 1,
and saves my friends a lot of hassle figuring out why I use zero to mean
true (confuses me sometimes too!).  I agree that they needn't be primitives
though.

> > 4) Given that we have catch and throw, do we necessarily need
> >    unwind-protect as a primitive?  (Do we need it at all?)  I *think* this
> >    is a reliable implementation:
> >         fn unwind-protect body cleanup {
> >            catch @ args { $cleanup; throw $args } { $body }
> >            $cleanup
> >         }
> 
> now that $&noreturn has made it into the language, we probably don't
> need unwind-protect to be a primitive, but a correct implementation
> is hard so i'd like to retain it, but not as a primitive.

Yes keep unwind-protect.  I've grown accustomed to it because it's so
useful, I use to have to trap just about everything in sh-scripts
(inevitably missing some signals out).  I agree with Paul that is should be
in the language as it's not trivially implementable.

> > 5) Since you can't change the state of the `-n', `-v', and `-x' flags
> >    during the lifetime of the shell invocation, I think they and the
> >    various `%eval-noprint', etc. dispatchers ought to be redone.  One idea
> >    is to have a single dispatch function called %dispatch which users can
> >    redefine to do what the various aforementioned flags normally cause to
> >    happen (which is generally thoroughly trivial).
> 
> perhaps.  i need to think more about this.

Having a changable %dispatch would be good, but then you'd have to forsake
the lexical binding of dispatch wouldn't you?

> > 7) I have mixed feelings about getting rid of the read syntax for special
> >    characters (e.g. `\n').  But I lean toward eliminating them for the sake
> >    of simplicity and reliability.
> 
> this is the one piece of es that nobody besides me seems to like at all.
> the complexity is very small, and it has some real advantages if you write
> scripts which include special characters.  i use \n all the time as the
> first argument to ``.

I've got used to \n etc, but I suppose I wouldn't miss it too much as I'd
just go back to what I did in rc. $nl, $tab etc.  I wouldn't have to quote
``\'' again.

> > $&split and $&flatten are arguably unnecessary, except possibly for
> > performance reasons (though I haven't noticed much of a difference in the
> > average case).  %split and %flatten can be implemented as follows:
> >	...
> > These could go in initial.es instead of using C primitives.
> 
> the semantics don't exactly match, but it's not a big deal.  

I like split and flatten, I've found so many uses for it.  I know it's
probably unnecessary but it's much better for efficiency to have it as a
primitive rather than written in es.

Here are a few more primitives that could go:
result, version, one

Pete.