Erling Hellenäs is playing with the idea of tying labels to the noun. The noun 
could have a label, labels could be tied to rows and columns. Addressing and 
indexing could then optionally be done 
with those labels.
For your information, using ordinal fractions this is done like this.
00 noun
10 first row
20 second row
01 first column
02 second column
11 array element 
12 array element 
21 array element 
22 array element 
Note that the digit value zero (0) is wild card character rather than index. 
/Bo. 

    Den 12:33 mandag den 4. december 2017 skrev Raul Miller 
<rauldmil...@gmail.com>:
 

 Ok, so https://en.wikipedia.org/wiki/Associative_array rather than
https://en.wikipedia.org/wiki/Association_list?

For this, I think I'd use a pair of lists - one of keys, one of
values. Possibly I'd stick them in a pair of boxes so I could pretend
to be using a purely functional parameter system. But given the
emphasis on mutability here, I think I'd prefer to refer to them by
name. I'll think about this a bit and probably add a note to the
referenced rosettacode entry.

If I were adding a type to J, I'd probably want to borrow K's table
type (probably including deep ties to the assignment operations and
the part where you can transpose them to get a different
representation, though I'm not sure that |: would be the way to
achieve that kind of transpose).

Thanks,

-- 
Raul

On Sun, Dec 3, 2017 at 4:06 PM, Marshall Lochbaum <mwlochb...@gmail.com> wrote:
> 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 <dabro...@indiana.edu> 
>> 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
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm

   
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm

Reply via email to