Ask HN: Do you know any computer language where collections are unified?

Clojure sequences (https://clojure.org/reference/sequences) provide some of what you are looking for:

"Clojure uses the ISeq interface to allow many data structures to provide access to their elements as sequences.

The seq function yields an implementation of ISeq appropriate to the collection.

Seqs differ from iterators in that they are persistent and immutable, not stateful cursors into a collection.

As such, they are useful for much more than foreach - functions can consume and produce seqs, they are thread safe, they can share structure etc."

Seqs do not handle the "here is my requirement, pick a collection for me" feature you want, but rather "here is a collection, run this algorithm"

Right, seq looks like a single way of accessing various collections when you need to access them in a specific manner.

If I want to access the collection iterating through it in read-only manner I'd just use seq. But I'm not guaranteed that ISeq I got will be fast. It will be as fast as possible for my collection, but what I want is to create a sequence where ISeq is fast, and also for example which I can access and modify by index and also where I can add values in front fast, and also possibly some other requirements.

Basically what I want is the ability to specify which operations I need to be fast at creation time, and get appropriate collection for that. And syntax of those operations should not change if requirements change.

Simpler way might be defining which data structures I want my collections to use, and get fast operations enabled by those data structures through common syntax.

For example:

    var mp = string[] is array, set, stack
    mp[5] = 'hello'
    mp.has('hello')
    mp.pop()

are all fast.

In Rust in theory you could express each capability a collection can have as a trait, impl the relevant traits for each container type, then write generic code that specifies it requires e.g. `NumberIndexable + FastAppend`. But AFAIK there is no way to ask the compiler to find the best available container type satisfying those traits; it would enforce anything you pass into the function satisfies them but wouldn't deduce it for you.

You could definitely do it with C++ template metaprogramming and type traits.

PHP lets you treat arrays and hashes exactly the same (or at least it used to) but I don't know if it switches the underlying data structures/algos based on usage.

I always considered it to be a very good decission in the design of PHP language.

This was a terrible decision, it causes so many functions to have different arguments to handle both data structures. It also slower performance wise

Since it's a scripting language made first and formost for accesibility not for speed it was a great decission. Because you could create nearly all the data structures you needed using just array() and many of them superbly easily.

There's a few different aspects to your question.

> For example, you might specify that you require collection to be indexed with numbers...

You can't hide that, because in at least some of the uses of that collection, you're going to index it by numbers.

Other than that kind of detail, though, I think you can create collections that you can use without knowing the details in Haskell. To a lesser degree, you can in C++.

The last detail is creation. You might be able to create a "collection factory" to create it for you. But I'm not sure that it's any different to say "CollectionFactory.createCollection(FAST_FIND)" than it is to say "new HashMap()". I mean, the former means that you don't have to know that a HashMap is the collection you're looking for, so that's something. It's not all that much, though.

But I want to be able to say:

CollectionFactory.createCollectionFast(FIND<string>, FIND<int>, STACK_ACCESS, KEEP_INSERTION_ORDER, REVERSIBLE)

This might require resulting collection to use multiple data structures in parallel to provide me with all the fast capabilities I listed.

Surprisingly, one "language" actually fits pretty well (most of) your requirements: SQL :)

What I have in mind is a general purpose language that you could build relational database in, that would use the same language syntax for queries that this language uses for simpler collections like array or set.

When you try to use SQL as a general purpose language syntax is not that great and not that unified.

Core Foundation (Apple’s C library) sort of uses this with its “array” type: https://ridiculousfish.com/blog/posts/array.html

Lua and PHP as the biggest ones. They both unified tables and arrays.

But you can do that with every library by yourself.

I'm probably wrong, but I feel like the Scala standard library is pretty close to what you are describing.

This is really super close.

Interface is really consistent, for example List and HashSet both have diff operation.

You could probably write a function that will supply you with the collection best fitting your requirements.

What I'm missing is combining multiple collections into one variable for sets of requirements that no single collection satisfies.

Also I'm not sure if Scala syntax could support other ways of accessing than simple indexing, like for example multi-dimensional indexing and slicing or even slicing by some inequality conditions like SQL does (with use of indexes into data). Basically if you could write LINQ and J in Scala syntax.

Even if not, the Scala collections look amazing and thank you for pointing me in the right direction!

After further inspection of Scala 3 capabilities, especially code quoting and splicing it seems that Scala 3 has all the building blocks necessary, base collections with consistent interface and syntax expressive enough to take it where I want it to be (Linq and J).

Lua metatables might fit the bill.

Lua metatables are quite interesting and you could probably implement a lot of the functionality I described in hacky/magicmethody manner.

I'm now looking at Scala collections library and it seems that large part of what I'm looking for was actually overt design goal of people who made it. They also thought about making customized collections easily with design that enables very aggressive code and interface reuse.