[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: creature = `feep
> >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).
don't worry. it's (mainly) just a straw man. i think backgrounding stays
for rc compatibility.
> >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.
reasonable approach. on a case by case basis, it should be considered.
> > ; 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.
it certainly makes es more complete, but i don't think it's gotten much use.
i still consider it a toss-up, but will probably stay.
> 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.
ok, i'm beginning to lean towards moving this out of the shell, as long as
there is a good examples file. it definitely goes back in my .esrc but that
does seem reasonable. i still want to hear more opinions on 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 use them extensively in scripts. besides, they're completely upwards
compatible with their /bin equivalents, only 1000x faster, so they add
no conceptual baggage. (and result 0 and result 1 are short enough, but
not clear enough. can you think of anything other than unix shells where
0 is true? i consider this a unix bug at least as serious as the spelling
of creat.)
> 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.
i don't buy the ``primarily an interactive feature'' so it doesn't belong
argument.
> 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) }
> }
> ?
well, there's an isabsolute test in there also. perhaps it should go.
right now, it duplicates code in eval; my feeling is that it should be
a hook that's kind of like a super-pathsearch. jury is out, but this
is much more an implementation issue than a bloat one.
> 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.
i like this more and more. i need to think about it.
``. -i'' is quite useful, and esdebug uses this stuff, too.
> 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.
on the other hand, a line that has two different ifs strings is trivial to
do with `` but ugly (not impossible, but ugly) with ifs. `` is a generaliztion
of `, so it stays.
> 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.
this reminds of a note from the haskell mailing list.
Phil Wadler says:
You are quite right. I'd forgotten about local rebinding,
because I feel that all local rebinding should be disallowed.
Anyone want to start a movement to eliminate local
rebinding? (1/2 :-) Cheers, -- P
And *I* think we should stop using names altogether and program in
terms of SKI combinators! Since these constructs have well-known,
unchanging meanings there is little chance that a program will be
misunderstood*. I don't know about the rest of the people reading
this, but I find the notation S(S(S(KS)K))((S(S(KS)K))(KI)) =
(S(S(KS)K))(S(S(KS)K))(KI) to be much more precise than the n+k
equivalent, 1 + 1 = 2. The similarity of the latter notation to the
informal numerals of everyday life is an open invitation to sloppy
reasoning leading to widespread program bugs. Besides, anybody who
can't handle needless complexity shouldn't be fooling around with
dangerous machines such as computers.
-- Dan Rabin (rabin-dan@cs.yale.edu)
yes, lambda is the most general form. but es does have syntax for people's
convenience. for is so simple i really do use it a lot. and, it matches
peoples' expectations coming from other shells. (i know that the cultural
compatibility argument can be taken too far. tell me if you think i'm doing
that.)
> 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).
> 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.
yes, but it's useful for code that needs to cleanup for itself:
signals = $signals sigint sighup
tmp = /tmp/foo.$pid
unwind-protect {
cat > $tmp
...
} {
rm -f $tmp
}
you are just about guaranteed that the rm is going to happen. (exit or exec
are the only ways it doesn't, and i'm considering changing exit to an exception
from just doing the exit(2) call inline.)
> 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
> }
actually, it's not that easy, either, in case the $cleanup code
raises a ``restart'' exception. and the result of the unwind-protect
is supposed to be the result of the body. i think it has to be
fn-unwind-protect = $&noreturn @ body cleanup {
let (exception = ) {
let (
result = <= catch @ e {
exception = $e
} {
$body
}
) {
$cleanup
if {!~ $#exception 0} {
throw $exception
}
result $result
}
}
}
> 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".
agreed, but there's a balance here. we hope to make es substantially faster
when it moves to a properly tail-recursive implementation. for now, it's
not going to happen, so the performance argument wins.
> That way lies GNU Emacs.
interesting comment, given its source. :-)
> 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.
i'm not sure i agree. wrap will probably go in in 0.9, but with a BUGS
section comment that it might disappear if someone
> 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.
first class environments will not appear before 1.0; when/if they appear,
they will piggy-back off of closures. (in fact, all a closure is is the
combination of a first-class environment with a lambda.)
> 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. :-)
flaming :-) and i have as weak a constitution. i've been answering mail for
more than an hour this morning.
paul