OK, what I'm trying to say is that the concept of executable and data needs to be extended to the J environment. For example, a class definition is essentially a read only executable. And, as such, should be distinguished from data, an object. If multiple instances of J are running then the class definitions should somehow be shared among the J instances. That is, the definition of the class should be in shared memory as all instances are identical. At least, that's how I understand that it should work in the C environment. Why not also in J?
Likewise, the standard libraries are identical if multiple instances of J are running. Why should each instance have its own copy of the definitions? This just causes a bigger load on the real memory requirements. Needless to say, there are questions on what happens if we are dealing with different versions of J running simultaneously. Or worse, the same version of J but different versions of the standard library. Well, that's the same problem facing C. I think that C addresses that by sharing based on the same file being referenced. J already knows what file names are defined by a script already. Why not provide a variation of load or require which puts the names defined by a script into memory that is shared by all instances of J? Since the full file name is given for these name definitions they can be assured to be identical. Any names redefined after the modified load would not be in the shared memory, but unique to each instance of J. IBM mainframes defined a couple of attributes for load modules, reentrant and refreshable. I especially liked refreshable. They simply meant that the modules went into a storage subpool that was read-only. It could not be modified once loaded. Those names cannot be changed. That sounds a lot like the definition of a class. I guess that I'm trying to go a little further with this concept, given the flexibility given by the ability to redefine a name in J. Let all names defined by load and require put the definition of the names into a read-only storage (executable) type of storage sharable by all instances of J (the same version of J, of course). Any redefinition of any name afterward defined by load would then no longer reference the version in the shared storage, but one unique to that instance of J. I think that already happens if a name defined by load is redefined later during execution. The name no longer has the file name of the load associated to it. This redefinition of a name cannot be done in C as the name is defined in read-only storage. But the dynamic naming in J allows this extension. J is unique in that the distinction between what is executable and what is data is fuzzy. A verb can be defined by a conjunction or adverb. But what is clear in J is what every name defined by load has a file name associated with it. Use that to control sharing. On 7/14/07, Raul Miller <[EMAIL PROTECTED]> wrote:
On 7/14/07, Don Guinn <[EMAIL PROTECTED]> wrote: > As I understand it, current computer architecture does not distinguish data > memory from executable memory. Distinctions are made by the contents of > registers. In the Intel platform, CX and DX type registers determine if > memory is being addressed as instructions or data. More modern machines also have a fairly elaborate system of caching and page managements, and "executable" or not is a property of a "page" on these machines. > Eric, your comment about distinguishing between executable memory and data > memory brings up an interesting point. One which probably belongs in a > different subject line. Verbs, adverbs and conjunctions are executable from > the J perspective, but are data from the C perspective in which the J engine > is written. What about making this distinction at the J level? I don't understand what you are trying to say here -- are you saying that the J language should make distinctions based on C syntax and the inner details of C compilers? What useful thing would this accomplish? > In addition, many of these name, and many nouns loaded at J initialization > never change. They should be sharable between multiple instances of J. Why? Your use of phrases like "never change" and "should be" makes it sound as if you are talking about a premature optimization. -- Raul ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
