[Prev][Next][Index][Thread]
Re: Closures
> Both are local but at the beginning z is unbound (so you get an
> error at runtime).
Ah ha! Thanks.
> > Ordinarily, I'd expect it to be the same as if you wrote z = 3 and
> > z = 2 both in g. That is, both assignments would change the value of
> > the same variable.
> ...
> The un-ordinary rule for a lisper [avoids] breaking even more code
> with the [addition of closures to the language].
I don't think it's only Lispers who'd expect it.
> And the need of a new syntax for introducing locals.
Not necessarily. What do you do now if you want an enclosed scope
in which there's a new variable with the same name as an existing
local? For example, in C/Java-like syntax:
int i = 0; // outer i
{
int i = 10; // inner i
... do things to i ...
}
... but the outer i is unaffected and still have value 0
If the language has no syntax for this, then either it already needs
one, or else it's ok not to have any way to do it.
> > > I think on the tradition of C and C++ Java is
> > > a bit scared about not explicit performance costs
> > > (Lisp absolutely not [1])
> >
> > Though I don't know exactly what in Steele and Gabriel's history you
> > have in mind, I don't think that can quite be true.
>
> Here's the passage:
>
> "This situation [performance difference between Interlisp-D and -10]
> of unexpected performance is prevalent with Lisp. One can argue that
> programmers produce efficient code in a language only when they
> understand the implementation. ...
But how do you get from there to "absolutely not" "a bit scared about
not explicit performance costs"?
I think the whole history of functional values / funargs / closures
in Lisp shows that there is a desire to avoid "unusual" performance
costs, and that it was only when it was understood how to do things
cleanly and efficiently that a solution to the various problems
became generally accepted.
-- Jeff