It seems to me that the biggest constraints on locale names are the word formation rules and parsing rules. Though there's also some name length issues (longer names are less likely to experience collisions, but can become unwieldy).
For example, perhaps we would want to have locales which can only be used indirectly, for the context of exported code? Something to think about. --------------- Beyond that, ... when dealing with large groups of people, the biggest problem becomes education. A common core of practices experiences quite a lot of turmoil (and unhappy criticisms) when exposed to people learning the language for the first time. So in that context, the biggest issue is not going to be whatever specific rules we have implemented, but our need for a wider variety of mechanisms for communicating the basic issues to our (currently hypothetical) audiences. Right now, we have code inspection, the documentation on the j software site (and a few other sites), and the labs, and the forums, and the various IDEs. Sometimes we have search engine support for some of that, other times not so much. Solving that realm of problem ... hmm... giving people small arbitrarily selected tidbits automatically (for example at the start of a session), might be a useful supplememt. Adding "documentation access" features to one or more of the J IDEs or the J command line might be a useful supplement. Creating an "exported locale browser" might be a useful supplement (pacman already has an example of this, but we currently don't have support for adding the work of trusted individuals, nor do we have a way for such individuals to indicate code quality, readiness and suitability of their own work). Anyways, I am not opposed to having jsoftware being somewhat central for code distribution. There's some significant advantages to longevity and diligence when importing code. We do need alternatives, of course -- but we *have* alternatives. And, while it's interesting to think about creating a marketplace for J code, ... I think we have some bigger hurdles to deal with there. Right now, the language is rather unstable, in the sense that published books contain J code which no longer works. The language itself has changed. And, while linguistic drift is expected, linguistic obsolescence hurts by adding obstacles for any potential audience. --------------- Short form: I don't think we're there yet (for "coping with many organizations and their locale name conflicts"), and I think we have bigger problems to solve. But the issue of "organizational name spaces" at the very least needs to be about package management, about onboarding new people, and not just about practical limits. That said, machine performance is important... That said, we need large projects here for a variety of reasons. That said, even more than that we need more useful projects here, for a variety of reasons. *Useful* is a more important issue than size. Thanks, -- Raul. On Fri, Sep 17, 2021 at 2:21 PM Eric Iverson <[email protected]> wrote: > > When I first designed/implemented locales, I fully expected that it would > be revisited at some point along the lines you suggest. But the flat > structure with copath has proven more resilient than expected. > > I look forward to suggestions in this area. But we want to keep it simple. > > A dead simple scheme like prefixes (j for jsoftware) similar to common port > numbers goes a long way in avoiding name conflicts. Not all in theory, but > perhaps enough in practice. > > On Fri, Sep 17, 2021 at 12:02 PM Michal Wallace <[email protected]> > wrote: > > > very glad to hear this! > > > > I think "big footprint" is what I was really getting at. > > > > Looking at my own code, I tend to use these "accessors" a lot more often in > > explicit code than in tacit. > > I still think there's a good idea there, but I now think it could be > > handled better with a verb-creating library > > than a special thing for names. > > > > I do have another thought about the `::` thing though, which is a > > new/better hierarchical naming convention for locales. > > Right now, importing a module might result in multiple conames being > > defined. (For example, importing my own > > UI library results in a coname being created for each ui widget class, and > > there's nothing I can do about that.) > > > > I worry that as more people start to create their own modules, we will run > > into issues with name collisions. > > I would love to be able to have `load 'tangentstorm/j-kvm'` generate > > exactly one top-level namespace, kvm, > > with other things underneath it: kvm::vm for viewmat, kvm::vt for > > terminal codes kvm::ui::edit , kvm::ui::list , and so on for individual > > widgets. > > > > I'm not necessarily trying to "claim' what "::" means, but... it's such a > > "big footprint" > > syntax, it should be used for something big. > > > > (I'll try to write this and my '..' thing as proposals on github this > > weekend) > > > > > > On Fri, Sep 17, 2021 at 10:46 AM Eric Iverson <[email protected]> > > wrote: > > > > > Michal, > > > > > > Your comment: "what's up with this new `name::` syntax?" > > > stirred up interesting stuff. > > > > > > The change was in a beta, so was intended to promote discussion. > > > > > > Henry's response: "Possession is nine points of the law. :)" > > > did have a smile, was a simple fact, and should absolutely not be taken > > to > > > mean that the discussion is over. Jsoftware has a good track record of > > > backing out of mistakes :) > > > > > > Your comment triggered a serious new look. We (back to that in a minute) > > > decided that: > > > 1. the change would lose a whole whack of good primitives: a:: A:: abc:: > > > etc:: > > > 2. self effacing is for esoteric performance and should not have such a > > big > > > footprint > > > > > > The next beta will probably adopt a spelling of name_: for self effacing. > > > > > > Your message triggered good discussion and time will tell if it boils > > down > > > to a solid proposal. Though I confess to being very leery of more > > mechanism > > > for assignment in tacit. > > > > > > The WE referred to earlier is myself, Chris, Henry, and Bill. This has > > > worked reasonably well since we lost Ken and Roger had less and less > > > involvement. > > > > > > We don't vote, proceed cautiously, and with consensus. > > > > > > The time is overdue for the involvement of more people and more formal > > > mechanisms. We will move in that direction, but cautiously. Probably the > > > first step will be creating a more appropriate media than the programming > > > forum for language changes. > > > ---------------------------------------------------------------------- > > > 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
