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