Associative indexing in APL (a need, an a possible way to...

Don't hold back

Associative indexing in APL (a need, an a possible way to...

PostPosted by FDA OSInet » Sun May 29, 2016 6:24 am

APL has never AFAIK officially known associative tables, or indexing tables with anything other than integer values. We cannot write (yet) :

CAPITAL [⊂'FRANCE '] ← ⊂'PARIS'

or, to remain in vector notation,

CAPITAL [ 'FRANCE' 'SPAIN' 'ITALY'] ← 'PARIS' 'MADRID' 'ROME'

which is unfortunate because:

1. Such an extension would ask very few syntax changes, and require none in existing programs;

2. Most modern languages ​​allow indexing by strings (or indexing arrays) as in PHP which allows to write $capital[ 'France'] = 'Paris' ;, or via similar objects like associative arrays in Perl (Perl requires using { } instead of [ ], because it interprets a string as "245" like the number 245; APL does not and would not therefore require that change;

3. Thare are few applications without a need to grant access by symbols rather than numbers. If APL does not allow that too, the developers will naturally turn to other languages meeting their needs better.

It is of course possible to bypass this gap at the cost of using additional variables, for example. FRANCE←33 would allow to write :

CAPITAL [FRANCE] ← ⊂ "PARIS"

⍎ 'FRANCE' will yield 33, but the application loses robustness and clarity, while unnecessarily cluttering the symbol table (Dyalog APL bypasses that with its namespaces concept http://help.dyalog.com/13.0/index.html? ... spaces.htm ).
Another way is to define a vector of names of countries: COUNTRY ← 'BELGIUM' 'FRANCE', the instruction then becomes:

CAPITAL [PAYS⍳⊂'FRANCE '] ← ⊂'PARIS'

Quite unclear. And in that latter case, regardless of the lower readability, the access time has no longer anything to do with direct access as "hashes" in Perl or PHP, especially if there are hundreds or thousands of names. Not only the readability of programs is impaired, but their serviceability collapses given the superimposed variables in the program.

Is such an extension in the range of NARS2000 plans ? I understand that a choice would probably have to be made separating integer-indexed arrays of enclosed-char-vectors indexed arrays, as reduction (/) and dimension (rho) would have trouble dealing with any kind of mixed indexing without losing compatibility. Of course, INDEX ERROR on write would never occur with enclose-char-vectors-indexed arrays either.

Just my two cents. Any suggestions ?
FDA OSInet
 
Posts: 24
Joined: Sun Aug 30, 2015 5:07 am

Return to Open Discussion

Who is online

Users browsing this forum: No registered users and 1 guest

cron