[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
everyone's least favorite creatures
Paul Haahr asks:
>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 see any good reason for making `pwd' a builtin, by the way.
`cd' is sort of necessary because of the design of unix (that is, child
processes cannot change the environment of the parent), but since any
child process can print out the current working directory, it's not
necessary for the current process (i.e. the shell) to do 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.
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.
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.
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
}
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).
6) Any history-related functions or variables. Tacking them into the REPL
is trivial for those people who really want history mechanisms.
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. Sometimes you just *have* to use eval
(although, fortunately, it's necessary far less often in es than it is
in sh). When you do, having special read syntaxes for those characters
is a major screw.
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.