Dan didn't really give you the whole story (well, I won't either, I suppose), so I'll discuss this a bit more.
An array in J (which refers to a multidimensional array, rather than just a list) consists of a shape given by $ and a ravel given by , . The entire ravel is stored contiguously in memory. Some other data, notably the type, is stored with the array, but that's about it. Arrays always follow copy-by-value semantics, but to avoid unnecesarily copying an entire array the J implementation may copy arrays by reference. As soon as the array is modified it will be copied to a new array. Arrays are reference-counted so that when the last instance of an array is removed, the array is deleted. Some notable operations which do not change an array and hence are implemented using copy by reference include assigning an array to a new name, boxing an array, and manipulating boxed arrays. We can investigate when arrays are copied by reference versus by value using 7!:2 , which measures the space used by the sentence given to it as an argument. If the amount of space returned by 7!:2 is less than the size of the array in question, that array must have been copied by reference. Here we create a large array and try some operations on it. Only the one which opens the box containing a and manipulates the value inside copies that array. 7!:2 'a =: i.300 400' 2098944 7!:2 '<a' 1280 7!:2 'b =: ($0) ; a' 2304 7!:2 '|. b' 1408 7!:2 '|.&.> b' 1050368 7!:2 '2 # b' 1408 7!:2 'c =: a' 1408 A final word of warning: as Dan says, this is an issue of implementation, not of language specification. Unless you are very concerned with performance, it is likely irrelevant to what you intend to do and I would recommend making sure you understand the way J handles arrays before asking questions about how they are structured internally. Marshall On Tue, Jul 08, 2014 at 01:56:30AM +0200, Erling Hellenäs 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) reassign vairables, explicit J is not > >functional, whether or not J reuses memory behind the scenes. Once you > >reassign a variable, you have no access to its previous value, whether or > >not that happens to still be in memory (ie, it's entirely possible for some > >previous value to be available to the interpreter but not to you). Again > >this applies irrespective how you achieved your modification, be that + or # > >or } or anything else. > > > >In fact, the current implementation of explicit J (unlike the current > >implementation of tacit J) does offer the J programmer the option to > >optimize by reusing memory in certain cases, amend prominent (and mapped > >files notorious) among them. And amend is famous and mapped files infamous > >precisely because reuse of memory corresponds to reuse of variables in the > >former case and not in the latter (that's worth thinking about, BTW). > > > >But the key is that's an implementation detail. a performance optimization, > >a convenience extended to the user. It has nothing to do with J qua a > >language, or the ability to formally reason about programs and their > >correctness. It's the existence of variables and the ability to reassign > >them that makes a language functional or not, not the tools it provides (or > >doesn't) to express calculations. Explicit J has variables and lets you > >reassign them; tacit J does not and (thus) can not. In short: tacit J is > >functional and explicit J isn't, and that doesn't depend, in either case, on > >what calculations you use, whether it's + or # or even } . > > > >-Dan > > > >[1] In fact the constraint is stronger: tacit J expressions don't even > >mention "data" (witness the absence of a lambda, just processes), which is > >why we prefer the label "function-level" as opposed to straight > >"functional". > > > >In other words, a function-level language is concerned with the composition > >of processes, whereas a functional language puts the focus on being > >side-effect free. This difference in focus may be one reason even pure tacit > >J is not truly functional (especially that non-functional bugbear !:). > > > >Please excuse typos; sent from a phone. > > > >>On Jul 7, 2014, at 6:07 PM, Erling Hellenäs <[email protected]> > >>wrote: > >> > >>A principle of functional programming is you never modify a variable? What > >>Amend does is create a new variable from other existing variables? Nothing > >>is amended? /Erling > >> > >>On 2014-07-07 23:50, Jose Mario Quintana wrote: > >>>Erling wrote: > >>>" > >>>It's obviously not possible to do any amendments in tacit code? It is also > >>>less elegant to pass these three parameters in the two arguments in tacit > >>>code? > >>>" > >>> > >>>Well, Raul and I showed general verbs to perform amendments tacitly. Once > >>>I was as puzzled as you are (were?) but I found enlightenment; maybe you > >>>can find it as well: > >>>http://www.jsoftware.com/pipermail/general/2000-September/004192.html > >>> > >>> > >>> > >>> > >>>On Mon, Jul 7, 2014 at 1:53 PM, Erling Hellenäs <[email protected]> > >>>wrote: > >>> > >>>>It's obviously not possible to do any amendments in tacit code? It is also > >>>>less elegant to pass these three parameters in the two arguments in tacit > >>>>code? Any opinions about the use of From to do the same thing? > >>>> > >>>> > >>>>NB. x and y are arrays of the same rank > >>>>NB. q is a boolean, also of this rank > >>>>NB. The expression merges x and y. > >>>>NB. Where q is TRUE it picks from y, otherwise x > >>>>NB. q {"0 1 x,"0 y > >>>> > >>>>If q is a vector and if we actually have a variable z of rank (+/q),}.$y > >>>>we can easily create x from q#^:_1 [ z ? No use for any indexes? > >>>> > >>>>/Erling > >>>---------------------------------------------------------------------- > >>>For information about J forums see http://www.jsoftware.com/forums.htm > >>---------------------------------------------------------------------- > >>For information about J forums see http://www.jsoftware.com/forums.htm > >---------------------------------------------------------------------- > >For information about J forums see http://www.jsoftware.com/forums.htm > > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
