Re: feeping creatures, again

[haahr@mv.us.adobe.com (Paul Haahr)]

i do understand Alan's concerns that we're trying to do too much with es.
perhaps lambda's are too much.  we could have, for example, picked up
tcl's upvar mechanism rather than using lambda, but lambda seems so much
cleaner.

in terms of mine and Byron's thinking, lambda (actually, argument-less
program fragments and then lambda) came first, and hooks were a much
later introduction.  (nobody saw hs, the hypothetical shell, which in
fact was rc + closures, which wasn't bad to use, but feels like a subset
of es now.)

of course, when we're justifying es, we talk about lambda as if it's there
to make hooks happen, and in fact, i don't think you could do the spoofing
that es encourages without lambda.  nonetheless, es really did come into
being when Byron and i started discussing what it would be like to make rc
into a real programming language.

now, why do i think lambda is essential for making hooks work?  aside from
avoiding all the usual name-collision issues, which i do consider necessary
for making es work with lots of functions, the construct

	let (search = $fn-%pathsearch) {
		fn %pathsearch { ... }
	}

requires closues, and has terrific semantics:  the binding to the old
definition is part of the new definition.  that makes it possible to
do multiple spoofings of the same hook without worring that __old_search
isn't being clobbered.

lambda stays.  it's essential to es.  it makes hooks just fall out.

paul