Re: everyone's least favorite creatures

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

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 don't see any good reason for making `pwd' a builtin, by the way.

pwd won't be builtin.  (did anyone ever really suggest this?  i hope i didn't
encourage it.)

> 2) The `apids', `var', `vars', and `whatis' commands.  Typing convenience
>    isn't a good enough rationale for having them.  If people want them,
>    they can put them in their .esrc (I see no reason why more sample .esrc
>    files can't be in the distribution).  Particularly for `apids' and
>    `var', doing by hand what they do is simply not that much effort. 

vars: it's more than the others.  it actually does something useful.

whatis:  catching the exception is enough to justify its presence.
(did 0.84 catch the exception?  my current version does.)

apids, var:  these two are not that important.  should they disappear?
(note that %apids and %var would stay.)

>    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.

(in fact, consulting my history log, i find 33 out of 19036 commands
were run in the background.  of those, all but 12 were for testing
es's implementation of backgrounding, and all but 2 of the remaining
commands were ``rm -r'' or ``tail -f''.  when pushed, i would get
backgrounding out of es before many of the other constructs under
discussion, and replace it with an external program that forked
and returned right away.)

who uses these constructs?  are they useful?

> 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.

> 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.

> 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.

btw, note that the value of those flags is effectively locally bound.
each new interpreter invocation gets a new one.  (``. -vx file'' works,
for example.)

> 6) Any history-related functions or variables.  Tacking them into the REPL
>    is trivial for those people who really want history mechanisms.

difficult since %parse can't run es code.  (this is an implementation
issue.)  $&sethistory and $history can probably be moved to initial.es
when/if the parser is revised, but that's a post-1.0 feature.

> 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 ``.

>    Sometimes you just *have* to use eval
>    (although, fortunately, it's necessary far less often in es than it is
>    in sh).

very, very rarely.  the only eval in my own code is used for the output
of -p and --p.  that's not to say that every use of eval is wrong, but
you should think twice before using it.  it'll probably bite you.
(i consider eval es's version of goto.)

remember, the official definitions of scheme do not include an eval
procedure, though almost every implementation does.

>    When you do, having special read syntaxes for those characters
>    is a major screw.

really.  'splain further.  is it any worse than single quote?

> 8) Comments in initial.es suggest you are thinking of providing a getopt
>    builtin of some sort.  Please don't---getopt routines are invariably
>    deficient in various ways.  For example, would your primitive support
>    GNU-style long options (which I would personally require)?
>    Getopt can be done in es script, with maybe just a trivial amount of
>    help from sed.  I don't think it's worth adding as a builtin. 

the comment is just idle musing.  i don't like the way that vars deals
with its options, but adding getopt to es is unnecessary.  an external
function would be useful, though.

fixed in 0.9.  (the comment was removed.)


and then, in a later note, Noah also writes

> $&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.  

> Another thought: Unless the \n, etc. hackery is removed from the shell
> (which I think I favor doing), get rid of the -n option to echo, and make
> echo not supply a terminating newline by default.  Lines which require a
> newline can do so explicitly.

echo has exactly the right behavior right now, imho.  on the other hand,
-- and -n interpretation could be done in initial.es rather than in $&echo,
and $&echo could be a straight call to write(1, ...).  doesn't seem
to make a big difference to me write now, so for now i'll keep it the
way it is.

paul