On 7/14/07, Don Guinn <[EMAIL PROTECTED]> wrote:
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.
In J, a class definition is not read only (I use this aspect when developing new classes). Also, near as I can tell, an "executable" is an OS concept, not a language concept. So I don't know what that means in the context of J. I suppose you could say that an "executable" in the context of J is a verb, adverb or conjunction, but a class is none of those.
And, as such, should be distinguished from data, an object.
If I have a reference to a locale, I can trivially distinguish whether that reference is a class reference or an object reference. referencetype=:3 :0 if.y e. conl 0 do.'class'return.end. if.y e. conl 1 do.'object'return.end. 'undefined' ) But, of course, from a language point of view, both are locales, and requiring their support for names be different would make the implementation more complex (bulkier and less efficient).
If multiple instances of J are running then the class definitions should somehow be shared among the J instances.
You can certainly load the same script in multiple J instances.
That is, the definition of the class should be in shared memory as all instances are identical.
All instances can be thought of as identical, but this does not seem to be reason to use shared memory. For example, the other day I was modifying the 'jzgrid' locale. If J had the requirement that this must be shared, there would have been no point in me starting up a fresh instance of J to test my changes while leaving another instance of J with an unmodified copy.
At least, that's how I understand that it should work in the C environment. Why not also in J?
I disagree here as well. First off, you are probably talking about C++ rather than C, as the big difference between the two was the introduction of a built-in implementation for classes and objects in C++. In C, the implementation of classes and objects is entirely up to the programmer. Second off, C (and C++) are traditionally implemented as compiled languages while J is traditionally implemented as an interpreted language. Also, the use of shared memory, or not, in the context of C++ classes is an OS issue as much as it's a language issue. It can also depend on some choices the implementer makes about how the program is linked. Or, you could be talking about how C loads dlls, which is yet another concept...
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.
First off, it is not a given that this causes a "bigger load on the real memory requirements". The management overhead associated with shared memory is not trivial and can easily be more expensive than the cost of something the size of J scripts. This gets even more complicated when you factor in memory management. Second off, development and interpreter use also seems sufficient justification for each having a unique copy in each interpreter which uses such. Third off, in J it's data, not code, which gets big. And an implementation of read-only shared names would have further complexities and costs. Anyways, it seems to me that introducing a mechanism like this should require some better justification than a loose analogy to what "should" happen in some different language.
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.
I think you are talking about how the OS uses shared memory for shared libraries (dlls). That's more like how J's 'cd 'mechanism than J's 'require' mechanism.
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.
Well... I can sort of see that J might get use from having shared names. But it would be easiest for J to implement this by having an extra copy as the "shared" names, with each implementation copying data out of the shared region during an appropriate time in its main loop. This would avoid some rather significant complexity costs.
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.
http://en.wikipedia.org/wiki/Class_(programming) In an interpreter, "compile time" and "run time" are the same. Only if you redefined the semantics of J (replaced the dictionary) would it be safe to have "compile time" precede "load time".
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.
Ok... that's different from what you have described earlier in this page. That's still hugely complex (for example, names are created based on what is loaded, so already you have an implementation detail, which you want to be immutable, which changes after the "file load" ). Anyways, efficiency is not a good justification for this concept. This change would make J less efficient (and possibly radically change the language, as the consequences of this approach cascade through the design).
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.
I do agree that C and J are very different languages.
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.
J is not the only language where the same "thing" can be treated as code or data. In fact, I think most interpreters (and incremental compilers) are similarly casual in their treatment of memory as "code" or "data". Anyways, there are good (simplicity and efficiency) reasons why J's support for mapped files only supports certain kinds of nouns. I can imagine implementation changes in the future which could change the face of these reasons, but a J which supports what you have described seems like it would have to be radically different from J6.01. -- Raul ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
