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

Re: Closures

Jeff Dalton wrote:

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

Together with first-class functions? and yes with lisper
I was referring to any non-purely but functional
(side-effects there, in particular assignment)
programmer
... in any case I have not written
"the just for a lisper un-ordinary " <wink>

>
> > And the need of a new syntax for introducing locals.
>
> Not necessarily.  ....
>
> 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 was not precise: the need of either a new syntax for introducing
locals, or for capturing variables in an outer scope even when assignment
to a corresponding identifier is locally present ;)

>
> >
> > "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"?
>

Sorry I'm a good guy <wink>, but I like hyperboles:
a bit scared about => absolutely not

and there was a: absolutely not  [because we can control the 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.

Agreed, but performance FUD (outside the enlighted circles) is
still doing bad, my web browser is not written in CL or Dylan
and OTOH crashes quite often...

Samuele.