[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