can a closure always be unwound and compiled in the same way that recursion can be converted to iteration? Even if yes, is this direction moving away from J's key strengths. Is there another way to solve the problem at hand that may lead to a something more elegant and scalable overall?
Flexibility is not always beneficial. These are all stylistic considerations and it's hard to judge the effect of these on the end result. Would love to hear from people who have embraced closures as a form for several years that also have an open mind to alternatives. Do closures lead to more mental strain or less? On 21 February 2013 06:32, Steven Taylor <[email protected]> wrote: > I have not yet seen a widespread use of closures in a language that > allowed them where it was a big advantage. I have had a few 'oh cool' > closure moments, but so far this has been isolated to specific cases... > Like when defining a function explicitly was tiring and interrupted the > flow of thought... And also as an alternate way of doing a state machine. > Are there any papers or open source examples you could point me to where > this style made a big difference to the outcome? > > Not trying to be contentious here. Interested. > > A reason not to adopt closures wide scale would be if you felt you wanted > to target a gpu. > > For me a closure is function+context. You could probably achieve some of > this with locales, but you'd need to limit recursive scoping to one level. > Does a j path get used to resolve nouns as well as verbs? Perhaps the > style could be taken further. > > Late to the thread. > > If this is more of a pragmatic discussion, consider interop to your > language of choice as a potential pattern. On the J way... I've more often > come to appreciate it. For example there is a movement towards immutable > structures and Apl has insisted on this for n decades. Someone, what is n? > > > > Sent from my iPod > > On 20 Feb 2013, at 22:27, "William Tanksley, Jr" <[email protected]> > wrote: > > > Raul Miller <[email protected]> wrote: > >> How is treating the "purely functional" case as having an element of > >> unreality the same as the idea that closures (in a stateful context) > >> are purely functional? > > > > If your definitions have "an element of unreality" they are incomplete > > definitions. Unreality is not part of a definition. (Nor is unreality > > the function of the subjunctive.) > > > > If you think closures CAN be used in a functional language, then by > > your definition you think a functional language with closures wouldn't > > allow mutable state, and that's what Boyko said. If you think closures > > cannot be used in a functional language, you haven't said anything to > > hint at it -- unless disagreeing with Boyko was how you hinted at it. > > > > Now, here's an interesting fact... Although some amazing people are > > using J to build dynamic functions, J is a descendant of a language > > called "FP" (invented by Backus) for which building dynamic functions > > was specifically disallowed. I suspect that this is the reason for > > some of J's restrictions on what sort of things you can return from a > > function. J has an interesting path ahead of it now! We can balance > > things out so that functions can return functions, in which case we > > can argue about closures; or we can take J back down the FP road, > > without closures. (Or we can stay on the same path we're on. I hope we > > do either of the three choices with our eyes open.) > > > > In FP, they call a verb a "function" and an adverb a "functional". > > > > No, that has nothing to do with our discussion. Except one thing: > > closures are impossible in a function-level language. > > > >> Raul > > > > -Wm > > ---------------------------------------------------------------------- > > For information about J forums see http://www.jsoftware.com/forums.htm > ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
