creature = `feep

[friedman@gnu.ai.mit.edu (Noah Friedman)]

Paul wrote:
>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.)

I might agree with this except that it creates a dependency on a
nonstandard external program.  It would also preclude the possibility of
implementing some kind of job control mechanism within the shell (although
I am finding myself less and less interested in actually implementing one).

>a lot of the suggestions have...been effectively ``move this from a
>primitive to initial.es'' and that's fine...but...it does nothing for the
>conceptual size of the shell, which is what is most troubling.

I suggested going from primitives to initial.es because that is a first
step toward eliminating them altogether (at the very least, if I have my
own initial.es I don't get those unwanted builtins).  If they remain C
primitives, it is harder to be convinced thay they can be eliminated
because no one has tried to implement them using other existing parts of
the language. 

>so, i solicit the list again for things that can go.  
>
>a couple of examples.  
>
>	; echo <={%fsplit '' foo}
>	f o o

Unless you forego %fsplit entirely, I think this is not only a very useful
hack (for example, getopt can be implemented without needing to run sed),
but even sort of sensible if you take it that there is an "empty" space
between each of the characters in a string.  If it doesn't take much code,
keep it.  Otherwise, {%fsplit '' foo} is just another way of saying 
{result foo}, which isn't that helpful.


What I definitely favor eliminating from es (including initial.es)
altogether are:

1) Anything related to "cdpath" searching.  I can't believe there aren't
   more people who agree with me on this even if they think the rest of my
   suggestions are out in left field.

2) true and false.  Really.  {result 0} and {result 1} are short enough to
   use explicitly.  How often do people actually need to refer to `true'
   and `false' values explicitly anyway?  Out of a couple thousand lines of
   es script so far I've only used `result 0' a total of five times, and
   didn't use `true' or `false' even once.

3) The `apids', `var', `vars', and `whatis' commands.

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

   How often do people really use it?  I have never used it even once.  I
   also find it hard to imagine anyone's scripts depending on it, so if
   it's primarily an interactive feature it ought to be sufficient just to
   drop it in your .esrc.

   By the way, even if you do keep `whatis' around, why is %whatis a
   primitive?  Doesn't it essentially just do

      fn %whatis arg \
      { 
        if { ~ $(fn-$arg) () } \
             { %pathsearch $arg } \
           { result $(fn-$arg) } 
      }

   ?

4) The various dispatch functions.  Just have a single user-definable
   %dispatch.  If `.' needs some way of defining a local dispatcher, you
   can do

      local (fn-%dispatch = $my-dispatcher) . file args...

   Maybe encapsulate this in a function if you do it that often.  I have
   yet to take advantage of the local dispatcher for `.', personally.


More things to consider removing, though I would push less hard for these:

1) The `` syntactic sugar. 

         pwent = `` ':' { grep '^friedman:' /etc/passwd }

   is equivalent to

         pwent = <={ %fsplit ':' `{ grep '^friedman:' /etc/passwd } }

   or even

         local (ifs = ':') pwent = `{ grep '^friedman:' /etc/passwd }

   I realize this is mostly a cultural compatibility issue with rc.  I
   still think it's unnecessarily redundant. 

2) `for'.  Harald's `each' definition is just as good (although you need to
   use $&noreturn to get the equivalent semantics of `for').  

   Since the strongest, most essential feature of es is lambda, I think it
   should be relied upon more heavily instead of making the grammar larger.

3) `eval'. 

   As has been pointed out, you really almost never need eval in rc and es
   (by contrast, in the bourne shell you need it a lot).

   At least one reason why `eval' isn't in R4RS is because R4RS doesn't
   require first-class environments, without which you can't specify in
   which environment the "second" evaluation should occur.  Perhaps, for
   the same reasons, `eval' should be removed from es.  On the other hand,
   most actual implementations of Scheme have eval (even those without 1st
   class environments), so some people must think it's useful even with the
   ambiguity about the environment in which the second evaluation occurs.

4) unwind-protect.  

   I find that most of the time I want to catch exceptions I want to
   examine what they are, so I use `unwind-protect' very rarely.

   Implementing unwind-protect is not complicated (but thanks for reminding
   me that it shouldn't catch return).

       fn-unwind-protect = $&noreturn @ body cleanup \
       {
         catch @ args { $cleanup; throw $args } { $body }
         $cleanup
       }
   

Features I think should at least be moved into initial.es:

1) $&flatten and $&split.  They are easy to implement in es script.

   Someone raised a performance issue with regards to doing them in es
   script.  It's true that they run substantially slower (particularly for
   large arrays), but this is an indication that es ought to be made faster
   somehow, not that you should bloat it with more primitives just in the
   name of "efficiency".  That way lies GNU Emacs.


Features not to *add*, at least not right away:

1) Hierarchical list support.  This is a wonderful idea that is now plainly
   obvious (:-)) but so much of the syntax required to implement them has
   to be inlined, and `wrap' performs so little of the work that I hardly
   see any justification for adding it at all.

2) Arithmetic.  You've given me some ideas that probably make it
   unnecessary for my purposes, so I retract my suggestion of adding it.

3) First class environments. 

   Before anyone starts seriously thinking about implementing this as yet
   another primitive feature, consider implementing them in terms of the
   existing closure mechanism instead.  I have very little time right now
   to think about it, but I have a hunch it's workable. 


Features presently in the shell for which I've recanted my desire to
eliminate them:

1) `\n' and related syntax for special characters.  I guess I am not as
   adverse to this as I once was.  There is already enough of a quoting
   nightmare when you use eval that things like `\n' do not make it
   substantially worse.


Well, I swore to myself I'd put off thinking about es until the end of the
week.  I have such a weak constitution.   Flame away.  :-)