On Wed, Feb 20, 2013 at 12:10 PM, Boyko Bantchev <[email protected]> wrote: > On 20 February 2013 17:25, Raul Miller <[email protected]> wrote: > >> Where? > > E.g. in > http://jsoftware.com/pipermail/programming/2013-February/031610.html > and in > http://jsoftware.com/pipermail/programming/2013-February/031617.html
Ok. But if I take those as definitions for "closure" I am unable to distinguish between "closure" and simple substitution. That seems like a big deal, to me. >> I thought I had provided some definitions (albeit, not for "closure"). > > That's right, not for closure. Which did not stop you from accusing > me of not accepting your (missing) definitions and not giving mine – > both these being false. > >> A "closure" is a reference to a subroutine combined with a reference >> to an environment which provides mutable definitions for the free >> variables (names whose definitions are supplied outside the body of >> the subroutine) referenced from that subroutine. >> That is the typical definition for the term, in the context of >> programming language discussions. > > Typical? Which discussions? And if the 'definitions' are not mutable, > is it not a closure? What is it called then? Well, for example, the last class I took. But I think the wikipedia definition of closure also is reasonably close to the typical case. As for the definitions not being mutable, those definitions are irrelevant. They can be included in the environment (and marked as immutable) or excluded from the environment (leaving us with potentially an empty environment) and both implementations can be correct. This avenue of discussion is like asking whether 0 is a number when it does not count anything. >> P.S. “Common sense is the most widely shared commodity in the world, >> for every man is convinced that he is well supplied with it.” >> ― René Descartes > > I would not dare disputing Descartes, but it seems to me that > considering dynamic binding, on the one hand, and source text > manipulation and recompiling, on the other, to be 'similar' tools > for effecting a program's behaviour (which you did) is definitely > a lack of common sense. They are similar in the sense that both can impose context. I'm not sure why you are having a problem with this. >> Without mutability there's no need for the environment and you cannot >> tell whether or not an environment is present ... > > What makes you think one must be able to tell? The closure has to > close over the non-local variables, as suggested by its name. How > this is achieved when those variables must remain immutable is an > implementational issue. Sure: you can have an empty environment, for example. But why should we be expected to make special accommodations for cases which cannot be distinguished? -- Raul ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
