[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: creature = `feep



In message <9305250958.AA08408@nutrimat.gnu.ai.mit.edu> , 
> 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.

I can agree with this.

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

I can agree with this.

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

vars is far from an interactive feature!

remove vars (functionality) and I quit upgrading my copies of es. :-)

Noah, vars exports the environment is an es friendly manner (i.e. nothing need be
done to the output to read it back into another es).

I use vars to export my environment from an es shell running on one machine to
a subshell running on another machine (via rsh).  Just like Plan 9's 'cpu' command,
I have an 'res' command that exports the complete working state of a shell to another
machine.  Without vars, I don't know how I would do this.

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

eval is used by 'res'.  I would hate to lose the ability to export an es' state
to a remote machine's es.

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

No comment. :-)

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

I really like \n, etc.  Please keep them in es.

--
Loren J. Rittle (rittle@comm.mot.com)
Systems Technology Research (IL02/2240)
Motorola, Inc.
(708)576-7794