Wow, that really is a terrible name -- especially now that "hash array mapped tries" are a popular implementation of persistent hash maps. I wonder if there's any way to justify changing the article name on Wikipedia.
The name HAT was given by its inventor Edward Sitarski in 1996. It looks like few people are implementing it and/or calling it by a different name. Because of this lack of development, it might not be possible to change the name to a more modern, neutral alternative.
Concatenative programming is definitely an overlooked paradigm. Factor and Forth(s) are worth trying out, if only for how they influence your thinking about software architecture in a minimal, compositional style.
Once you get down to PMAs and van Emde Boas trees I think those are fairly exotic by the standards of most programmers - you won't meet them in your standard undergrad CS course IIRC.
Seems like one possible implementation of std::deque, yeah. Dunno off the top of my head if the described implementation matches the requirements, though. IIRC C++ standard library implementations tend to use fixed-size chunks, except maybe the first and last chunks.
Note that the original article describes space complexity as "N + O(sqrt N)", i.e., there are N records and O(sqrt N) extra space.
Their data structure is considerably more complex than traditional implementations of std::deque, I wonder if it is actually of any practical interest.
* Random access - constant O(1)
* Insertion or removal of elements at the end or beginning - constant O(1)
* Insertion or removal of elements - linear O(n)
[1] does not mention a linear space requirement, it mentions O(1) time for random access and removal of elements. Both major implementations implement std::deque in this way libstdc++ [2] and libc++ [3], but you say it can't be so. Well well.
I don't get what you're arguing against, if anything. Can you make an actual claim and tell me where I'm wrong? Literally all I've been saying so far is that std::deque does not meet the O(sqrt n) space overhead of compact dynamic arrays. i.e.: yes it is more exotic than a mere std::deque, which is precisely the question you were asking and I was answering initially. So you're saying I'm wrong, or what? If you're saying I'm wrong, which implementation of std::deque do you think meets that overhead spec?
"No, std::deque has O(n) space overhead... the goal here is to get that to O(sqrt(n))," implies that compact dynamic array can't be used for std::deque, when it is used as such, also I did not find a source that states this space requirement for std::deque in the first place.
...you were asking what's so "exotic" about compact dynamic arrays if they're just deques? I'm telling you they're not deques, because they have additional constraints that deques don't have.
Are you intentionally twisting this backwards or something? You're basically turning the conversation into something like this:
You: "Penguins are birds, right? What's so exotic about penguins when I see all these birds flying around me?"
Me: "Penguins live in Antarctica... and don't fly... (hence why people find them exotic...)"
You: "But who says birds can't live in Antarctica?? And chickens can't fly either. And penguins are birds. So what's so exotic about penguins?"
Me: {what sane response can I even give you here?!}
________________________________________
But anyway...
> implies that compact dynamic array can't be used for std::deque, when it is used as such
To entertain your new argument here:
Deque requires references to existing elements not to be invalidated when new elements are appended. I don't know how compact dynamic arrays work, but dynamic arrays generally move elements around in memory while maintaining guaranteed worst-case O(1)-time access to them, so it seems kind of impossible for them to meet both requirements.
No. std::deque is like a vector of small arrays. Small meaning 32 to 512 bytes or one T if larger. Compact dynamic arrays have sub-arrays which can be larger and can be dynamically sized.
The small fixed size of the sub-arrays in std::deque is basically a defect making the container a lot less useful.
