The associative lists that Andrew is talking about (also called maps or dictionaries) are essentially the same as JSON objects (more precisely, JSON objects are maps whose keys are strings). There's no need for them to be used in a particularly low-level way, although the primitives used to manipulate them would have to be different from J's array primitives. Examples might be combining two maps but giving preference to one of them when they conflict, or inverting a map by swapping keys and values.
Lisp stands for "list processing", and its fundamental datatype is the linked list, composed of value-reference pairs. These aren't related to associative arrays, at least not any more than they are related to any other datatype. I feel pretty strongly that an associative array type is missing in J, but it's understandable given how hard such a type would be to specify and implement. That doesn't make it any easier to live without them, though. Marshall On Sun, Dec 03, 2017 at 01:50:43PM -0500, Raul Miller wrote: > <<< means "box three times" > > <2 > ┌─┐ > │2│ > └─┘ > <<2 > ┌───┐ > │┌─┐│ > ││2││ > │└─┘│ > └───┘ > <<<2 > ┌─────┐ > │┌───┐│ > ││┌─┐││ > │││2│││ > ││└─┘││ > │└───┘│ > └─────┘ > > See also the documentation on the index operation (Henry gave you a > reference for that). > > Also, as I understand it, JSON has only a loose relationship with > a-lists. My understanding of them is that they are the fundamental > datatype provided by the lisp / scheme / .. family of languages. > Basically, you're working with pointer chasing. In J, you can use > indices or names as references, if you want to build a workalike - but > usually it's just not worth the bother. > > And that "encode" method is building a name based on an arbitrary > string. You should probably think of it as a hash function. But > there's a typo - there should be a space after the v in inv. But this > suggests also that rosettacode is having bitrot issues with its > storage system, and that has all sorts of unpleasant implications. > Basically, you are not going to be able to use rosettacode > implementations - in the general case - unless you are prepared to > debug them (which kind of defeats the purpose of having the site in > the first place.) ... wait, no.. when I go to that rosettacode page, I > see a space after the 'inv' keyword. Well.. it could still be bitrot, > but perhaps at the cloudfront level rather than on the site itself... > > Thanks, > > -- > Raul > > > > On Sun, Dec 3, 2017 at 1:24 PM, Andrew Dabrowski <[email protected]> wrote: > > 1. Yes, I should been more specific: I wanted to know the idiomatic way to > > delete the nth item of a list, so I think <<< is what I was looking for. > > > > What is <<< called and where is it documented? > > > > 2. Not sure what you mean by "Their focus is on micromanaging the sequence > > of operations." A-lists are built into just about every other modern > > language because they're so useful at managing information. Does J not > > support JSON for web interoperability? > > > > One example is using an a-list as a structured object, without having to get > > into full-blown OO. I could represent the state of a model using an a-list > > and then update the values over time. > > > > I saw that using classes is one alternative > > (https://rosettacode.org/wiki/Associative_array/Creation#J). > > > > coclass'assocArray' > > encode=:'z',(a.{~;48 65 97(+ i.)&.>10 26 26) {~62x #.inv256x #. > > a.&i. > > get=: ".@encode > > has=:0 <: nc@<@encode > > set=:4 :'(encode x)=:y' > > > > I have absolutely no idea what is going on in the encode function. I hope > > there are other options. > > > > > > > > On 12/03/2017 12:59 PM, Raul Miller wrote: > >> > >> Why do you want to delete an item from a list? This is *not* a > >> rhetorical question - we have a variety of ways of removing items from > >> lists and to pick the correct mechanism we need to understand what you > >> are trying to accomplish. > >> > >> To illustrate, here are a few examples: > >> > >> list=: 2 3 4 5 7 8 9 10 > >> > >> NB. delete specific elements > >> list -. 3 5 7 > >> 2 4 8 9 10 > >> > >> NB. delete based on a computation > >> (0=1&p: list)#list > >> 4 8 9 10 > >> > >> NB. delete based on a range of indices > >> (3&{.,6&}.) list > >> 2 3 4 9 10 > >> > >> NB. delete values at certain indices > >> (<<<3 5 6){ list > >> 2 3 4 7 10 > >> > >> And then there's operations (like outfix) which offer regular > >> abstractions: > >> 3 ]\. list > >> 5 7 8 9 10 > >> 2 7 8 9 10 > >> 2 3 8 9 10 > >> 2 3 4 9 10 > >> 2 3 4 5 10 > >> 2 3 4 5 7 > >> > >> Note that "delete from a list" is a dual of "select from a list" - > >> maybe a shift in perspective can help? > >> > >> As for the lack of "a-lists" - again, why do you want them? Depending > >> on what you are trying to do, there's a lot of options. Their focus is > >> on micromanaging the sequence of operations, though, so you should not > >> expect the language to make most of your decisions for you, there > >> (unless of course you are working with a language which was > >> specifically designed with an "everything should be an a-list" > >> mentality - but that's not J). > >> > >> Thanks, > >> > > > > ---------------------------------------------------------------------- > > 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
