On Wed, Feb 20, 2013 at 3:18 PM, Boyko Bantchev <[email protected]> wrote: > On 20 February 2013 19:51, Raul Miller <[email protected]> wrote: >> But if I take those as definitions for "closure" I am unable to >> distinguish between "closure" and simple substitution. > > There sure is a difference between substitutions and closures. > Indeed, there is hardly anything in common between them. > But why you are unable to distinguish between them is not my concern.
For example, in http://jsoftware.com/pipermail/programming/2013-February/031610.html -- "Third, closures *are* purely functional. ... Closures are but a mechanism for effectuating the binding of non-local names." As I understand it, if closures *are* purely functional they would not allow state change. I think I would use a different tense (for example, subjunctive tense) to express that they have the potential of being purely functional. >> But I think the wikipedia >> definition of closure also is reasonably close to the typical case. > > Yes it is, only 'the typical case' is not what you present it to be, as > can easily be checked by reading that article. I thought that I had said "reasonably close" and that I had managed to avoid any use of words meaning "to be". > Amazing how you keep telling untruths, despite it being very easy > to prove you wrong. When I do, you just move to telling another > untruth. I don't know what kind of honesty this is. The wikipedia page mentions several cases: o The traditional case (which closely matches my definition). o The static case (where there's no point in referencing an environment and values are typically used directly - which I treated as an edge case) o The lazy case (where we eventually resolve to a value or to an error - and which is a subtle variation on the traditional case) And that matches what I have been trying to express. The wikipedia page also treats other issues (for example: binding of implicit variables, such as are used to implement some control structures). I was not trying to express those ideas. I will agree that there's superficial differences in wording, but it's the same concepts being presented there that I've been expressing. >>> 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. > > Sheer nonsense. You are refusing to make a difference between > how programs (and languages) work and merely writing those programs. If we are to allow only one definition for "closure" I see no need to incorporate this level of detail in that definition. >> But why should we be expected to make special accommodations for cases >> which cannot be distinguished? > > Your question is out of place. What the programmer will not > (and need not) be able to tell is how a closure is implemented. > But one can surely tell if there is a closure. Sometimes we can, sometimes we cannot. -- Raul ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
