You raise some interesting points, but first, I have to address a confusion I've seem come up before. It is this: arrays are not lists. Arrays are a data structure with O(1) indexing, designed to be accessed and not iterated over. Cons cells/linked lists are a data structure with O(n) indexing, designed to be iterated over and not accessed. What's more, if we have a dotted pair be an array of length two, we get
Cons vs. Array
-----------------------------------
(a . b) <---> [a, b]
nil / () <---> nil / []
(a . nil) / (a) <---> [a, []]
(a . (b . nil)) <---> [a, [b, nil]]
Arrays and lists have fundamentally different structures (one emphasizes first vs. rest, the other emphasizes here vs. there), and this is why mzscheme / PLT Scheme separates vectors (its arrays) and cons cells.
As for content: it seems to me that your title overstates your point. You appear to be arguing for the removal of hash tables as an axiom, which is different from arguing that they are "unnecessary". (To be fair, your second argument does propose to eliminate them, but you replace them with something with equivalent access "terminology" (though not speed nor mutability).) Hash tables (or really any sort of dictionary) and closures/anonymous functions are, in my opinion, the two most useful things in programming, so I feel that they should be part of the language; whether in ac.scm or in arc.arc doesn't matter to me as an Arc user. However, as someone who cares about the implementation, your point about simplifying the axioms and examining speed tradeoffs is a good one, and is worth considering (though I'll leave it for wiser heads than mine). It would be nice if we could get all our complex data structures out of one (or a few) axiom(s), and perhaps arrays would suffice; after all, they do for C.
