Certainly. But the exact same thing happens if you expose the object through an interface to a foreign system. (This has been the source of many browser woes,)
The alternative, of course, is to allow references to deleted objects to exist. But that just gets you into which part of the system has the right to delete the object and what the rest of the system is supposed to do after that happens. It's all misdirection. Thanks, -- Raul On Wed, Apr 14, 2021 at 12:26 PM Marshall Lochbaum <[email protected]> wrote: > > Using numbers (or string names) to indicate locales is what forces them > to leak. If an object is manipulated with references, an interpreter > knows they are references and can determine when there are none left. > With numbers, the interpreter can't know if a given number will be used > as a reference, and besides, even if a locale's number doesn't appear in > the session the user might compute it or retrieve it from somewhere. > > Marshall > > On Wed, Apr 14, 2021 at 10:38:45AM -0400, Raul Miller wrote: > > Hmm... > > > > There's some truth to this, though the "numbered locale" thing seems > > like an information hiding issue. Those numbers (or numbers which > > serve an analogous role) exist in other languages, but other languages > > hide them from you. > > > > And the "reference" or "first class" issue is ... rather subtle. > > Generally speaking, a shared "mutable object" is a reference which is > > shared. It's hidden from the programmer, but that's always what's > > going on. There's significant implementation costs here, though, and > > memory management issues (which play out either as code complexity -- > > for example in the C++ world, or system crashes -- for example rust's > > stack overflows -- or other forms of complexity -- for example the > > difficulties in Javascript's foreign language or os interfaces). > > > > Anyways... These are not non-issues. But they are time burners -- just > > talking about them has consumed countless hours and years of the lives > > of many, many people. > > > > Thanks, > > > > -- > > Raul > > > > On Wed, Apr 14, 2021 at 10:28 AM Marshall Lochbaum <[email protected]> > > wrote: > > > > > > The difference is that in the languages you list, an associative array > > > is mutable. A mutable object can be shared, and changes to one copy are > > > reflected in others. Immutable data is easier to reason about, making it > > > a better default, but mutability is essentially required to implement > > > many algorithms efficiently: Dijkstra's algorithm is probably an > > > example. Languages that have only immutable data structures might > > > provide mutability using lexical closures, but J doesn't have these: its > > > only non-local variables are locale-scoped. This means that locales are > > > the only mutable thing that J offers, and these aren't first class as > > > they can only be referred to by strings or numbers. > > > > > > In J the only two ways to create mutable objects that can be passed > > > around and updated efficiently are to (0) pass references that refer to > > > global data, which must be stored in only one place so it can be updated > > > in place, and (1) use numbered locales as objects. These are both very > > > unpleasant from a syntax perspective, 0 becomes much more difficult with > > > more structured data. Much worse, both of them require the programmer to > > > do their own memory management or write a garbage collector to avoid > > > leaking everything. This need for garbage collection is inescapable: J > > > manages memory with reference counts, meaning that if there are two > > > values so that either one can be used to "find" the other, each must > > > have a reference count of one and can never be freed, even if the pair > > > isn't reachable from the rest of the program. > > > > > > Marshall > > > > > > On Wed, Apr 14, 2021 at 03:00:42PM +0200, Hauke Rehr wrote: > > > > In J, there’s a single compound data structure (henceforth, CSD): > > > > the rectangular homogeneous array of arbitrari dimension. > > > > What’s so bad about having only a single CSD? > > > > > > > > Many languages start with the associative array (henceforth, AA). > > > > In D, for example, you have types T[S] where T and S are types. > > > > [Oftentimes, AAs are implemented as hash tables, best known AA flavor.] > > > > They usually provide custom syntax and specialized implementation for, > > > > in the D syntax example, T[int] with indices starting from min ℕ, > > > > for whatever that means to the language (usually, 0 or 1). > > > > Those are called arrays. > > > > Many other languages start with nothing but arrays and AAs, > > > > as well (cf. Perl sigils @ and %, for example [yes, I don’t raku yet]). > > > > > > > > I’ve never heard as harsh complaints about, for another example, > > > > lua having only a hash-table-array-hybrid – let’s call it a hash table: > > > > you can imagine the array part of it as syntactic sugar > > > > with good performance. > > > > > > > > No, it doesn’t hurt a language to have been built with a single > > > > CDS at its core. > > > > > > > > > > > > > > > > Am 14.04.21 um 13:45 schrieb Julian Fondren: > > > > > The complaint isn't "a program like that can't be written", or the > > > > > argument would be that J isn't even Turing complete. The complaint > > > > > is "I can't write a program like that in the manner I'd like." > > > > > > > > > > Quotes: > > > > > > > > > > * No non-array data structures: hash tables, trie, graphs, etc. This > > > > > is a show stopper because so many problems are easier to reason about > > > > > and to solve by picking a more suitable data structure. > > > > > > > > > > I reason about those things in terms of mathematics and abstract > > > > > structures: I'd venture to say that's par for the course because its > > > > > easiest. > > > > > > > > > > Suppose you want to translate a program you've written in a non-APL > > > > > language into J. Much of the program can simply be transliterated, > > > > > page-into-sentence, without much concern for the overall design > > > > > of either program... unless a non-array data structure is very > > > > > important. Now you have to think about how precisely the original > > > > > program is using the data structure and how you can do that in some > > > > > other way in J. > > > > > > > > > > The same speedbump shows up if you're following a tutorial, or trying > > > > > to implement an algorithm according to a book or paper's description: > > > > > as soon as a non-array data structure's properties become important, > > > > > there's an abrupt increase in the difficulty of your task and of > > > > > the depth of understanding of the problem domain that's required of > > > > > you. > > > > > > > > > > The abruptness is off-putting all by itself. Imagine a language where > > > > > + - * are all available but % isn't and the response to wanting it is > > > > > 1. have you considered solving your problem without division? It's > > > > > very expensive! With a constant denominator and fixed-width > > > > > integers > > > > > it's even possible to divide *with* multiplication by a magic > > > > > number. > > > > > 2. you can implement it yourself (with unusually bad performance) > > > > > 3. you can get it from the FFI > > > > > 4. is this so weird? ARM processors don't have % instructions. > > > > > > > > > > Yeah, it's pretty weird. Not having hash tables has also become weird. > > > > > > > > > > On 2021-04-14 05:25, ethiejiesa via Programming wrote: > > > > >> It's not J, but FWIW Dyalog APL apparently can boast this realistic, > > > > >> immersive simulation of some piece of Finnish coastline. The 3D > > > > >> engine is an external dependency, but supposedly everything else is > > > > >> straight APL: > > > > >> > > > > >> https://www.dyalog.com/case-studies/simulation.htm > > > > >> > > > > >> Since the core of that project is taking large amounts of data, > > > > >> scattered in lots of non-uniform formats, and munging it into a > > > > >> concrete realtime visualization, you might find it > > > > >> interesting/inspiring/helpful/whatever. > > > > > > > > > > ---------------------------------------------------------------------- > > > > > For information about J forums see http://www.jsoftware.com/forums.htm > > > > > > > > -- > > > > ---------------------- > > > > mail written using NEO > > > > neo-layout.org > > > > > > > > ---------------------------------------------------------------------- > > > > 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
