On 17 February 2013 19:43, Raul Miller <[email protected]> wrote: > For example, a dictionary search (using > http://www.google.com/cse/home?cx=016147560673599814097:rk5jmigdjse) > for the phrase "functional programming" finds me zero results.
So you are out of luck. Sorry, can't help. > I wish you would provide specific references, instead of vague references. > The only message I see from him in this thread is: It is the only message (itself of 2+ lines) and you call it 'vague references'? Again, sorry, but cannot help you. > Anyways, I do not see enough material here to think that I have a > valid basis for submitting a change to the wikipedia page describing > functional programming. I don't have even the slightest interest about whether you are contemplating editing anything or not, so please do not feel obliged to keep me informed on this otherwise extremely important subject. > Here, the phrase I have problems with is "not those of". As you yourself confess, the one that has problems is you. > I think we can have multiple discussions of closures, and I see > nothing wrong with some of them focusing on J. You are free to consider further contributing to this thread by concurrently participating in multiple discussions on the same subject – perhaps with yourself. > In a language which I would call a purely functional programming > language, there's no distinction between closures and currying. If you really think so, your problems with regard to understanding basic functional programming concepts are more serious than it was apparent so far. > In J, we might implement that like this: As far as closures are discussed, it is completely irrelevant whether or how you model a specific example in J. Having closures means automatically capturing non-locals that emerge from nesting. You might consider an example where *that* general concept is modelled, but, of course, there is no function nesting in J, to start with. > On the other hand, there's not enough code, here, to implement Paul > Graham's challenge -- the existence of lambdas alone does not give > you the persistent state changes that he was asking for. Graham's 'accumulator generator' requires more than lambdas. It even requires more than lambdas with closures. In addition to these, it requires that changing state (i.e., changing the values of certain variables) is possible. But again, as far as closures themselves are discussed, whether Graham's problem requires anyting beyond stateless functions is not of relevance. > Certainly. And we can use f. to fix this (for example) or we can > simply not redefine words. You can also abstain from programming at all – then the possibility of producing a stateful function almost vanishes. > A similar issue arises with Haskell when you edit the file and > recompile, or when you copy and paste and expression into some other > program (perhaps involving multiple programmers with blog posts or > email messages as a transport for the code snippets). Oh, dynamic binding in one programming language is similar to editing text in another one? A very interesting concept. ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
