The answer to all three of your questions, in the current implementation of J, is "yes" (where a "generalized array" corresponds to J's "boxed array").
But bear in mind that J is an abstract language, a notation independent of any implementation, and so future implementations may make choices which change any or all of the answers, or render them irrelevant or inapplicable -- all transparently to the user (ie you). In other words, all those things are implementation details, and the language and the ideas you can use it to express don't depend on any particular implementation. Changing the implementation doesn't change the language* -Dan * Well, except through feedback cycles: if you make something easier or more rewarding, people are going to use it more, and so the way people use the language will change, so the language definers might be tempted to change the language ... and so on. Please excuse typos; sent from a phone. > On Jul 7, 2014, at 7:56 PM, Erling Hellenäs <[email protected] se> > wrote: > > A generalized array is only an array of links to arrays? When you allocate a > new generalized array, the arrays it links to can remain? When you assign a > new array in a cell of your generalized array, all you have to do is set a > link to the array assigned to the cell? /Erling > > On 2014-07-08 01:11, Dan Bron wrote: >> J is not a pure functional language. But tacit J is a (n almost) purely >> functional subset of J (exceptions include things like ? and s:, but much >> more importantly !:). >> >> In particular, tacit J /has no variables/. You can't, in any way, modify a >> previous result, because you have no way to refer to a previous result. All >> you know about is your input(s), and all you care about is your outputs. >> Tacit J is no more than a notation for describing how to transform inputs to >> outputs. That's all any functional language is. >> >> Now, it happens to be that under to covers, J is copy-on-write, so that any >> time your tacit code amends an array (whether using } or + or %, which are >> conceptually the same), a new array is created and the original is left >> untouched. Sometimes a copy is made first and then modified, sometimes the >> new array is built up element by element, but that's irrelevant: an >> implementation detail. >> >> But then, so is the fact that J is copy-on-write. If the interpreter could >> somehow determine that there was no further need for your input array, and >> than from here on only your output would be used, then it could decide, as >> an optimization, to reuse the memory allocated to the input and under the >> covers make the smallest amendment required to produce your output. But the >> key is that the input and output are logically distinct and the notation >> treats them as distinct and presents them to you as distinct, and if the >> interpreter reuses some memory under the covers, that's no more than an >> optimization. Tacit J is a functional language, regardless if you express >> your transformation of input to output using * or # or } or anything else, >> because it /has no variables/ [1]. >> >> Now explicit J is different story, because there, you've got =: and =. . >> Now it happens that explicit J also happens to be mostly copy-on-write, but >> again that's an implementation detail. Since you have the logical capability >> to create, mention, and (critically ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
