APL n’a jamais officiellement permis d’indexer un tableau avec autre chose que des valeurs entières. On ne peut pas par exemple y écrire
CAPITALE[⊂'FRANCE']←⊂'PARIS'
ou, pour rester dans le vectoriel,
CAPITALE['FRANCE' 'ESPAGNE' 'ITALIE']←'PARIS' 'MADRID' 'ROME'
ce qui est regrettable, car :
- une telle extension ne demanderait que très peu de modification de syntaxe, et n'en demanderait aucune des programmes existants
- tous les langages modernes permettent l'indexation par des chaînes de caractères (soit l'indexation des tableaux comme en PHP qui autorise à écrire $capitale['France']='Paris';, soit via des objets voisins comme les tables de hachage en Perl).
- Très rares sont les applications où il ne faille pas gérer des accès par symboles plutôt que par numéros. Si APL ne le permet pas de façon immédiate, l’utilisateur se tourne de façon fort naturelle vers d’autres langages répondant mieux à ses besoins.
Il est peu ergonomique de contourner cette lacune au prix de variables supplémentaires, comme par exemple: FRANCE←32 (dès lors, CAPITALE[FRANCE]←⊂"PARIS". Si le pays provient d'une saisie, l'indice peut être retrouvé par "execute" : ⍎"FRANCE" qui rend 32, mais l'application perd en robustesse et on encombre inutilement la table des symboles (APL/X contourne la difficulté par des namespaces).
Une autre manière est de définir un vecteur des noms de pays : PAYS ←'BELGIQUE' 'FRANCE' , l'instruction devenant alors : CAPITALE[PAYS⍳⊂'FRANCE']←⊂'PARIS'
Mais en ce cas, indépendamment de la lisibilité plus faible, le temps d'accès n'a plus le moindre rapport avec un accès direct de type "hash" en Perl ou PHP, surtout si s'il y a des centaines de noms.
Non seulement la lisibilité des programmes n'y gagne rien, mais leur facilité de maintenance s'effondre compte tenu des variables supplémentaires ainsi surajoutées dans le programme.