Rich's opinion on the GPL question: https://groups.google.com/d/msg/clojure/bpnKr88rvt8/AOtLHW4Lhh4J

GPL is "viral" and a lot of companies categorically won't touch libraries licensed under GPL.

So, my dear fellow Clojurians, render for me in your mind, if you would, an imaginary data structure we shall call a #smv

in written edn form, it might look like this:

#smv [[0 :a "bob"]]

The first column is the key index colum of the vector. The second is the key column for the map relations. If a key relation is missing (#smv/nil) then the index for the row (its first element) defaults to the key

If we were to define one of these #smv like so:

(def smv
  #smv
  [[0 :a "bob"]
   [1 :b "ann"]])

Calling conj on an #smv act's like a vector:

(conj smv "ted")

#smv
[[0 :a "bob"]
 [1 :b "ann"]
 [2 :smv/nil "ted"]]

Calling assoc would act like a hash-map:

(assoc smv :granny "sue")
#smv
[[0 :a "bob"]
 [1 :b "ann"]
 [2 :smv/nil "ted"]
 [3 :granny "sue"]]

When executing sequential operations, only the last element of each #smv element is returned:

(vals smv)
#smv
("bob" "anm" "ann" "ted" "sue")

(seq smv)
#smv
("bob" "anm" "ann" "ted" "sue")

(keys smv)
#smv
(:a :b 2 :granny)

Now, I haven't actually gone an implemented such a structure, but would something like that seem worth experimenting with?

It's like a unified structure that can be acted upon by all functions that act on sets, maps and vectors

Under the hood, it would hold an extra hashmap, which contains a map of keys to index nodes on the vector, to preserve fast lookup

Point being, "it is better to have 100 functions operate on one data structure..."

So the idea would be, see how far that could be taken to the extreme

What I haven't worked out yet is how the set mechanics will work

But, in general, I'm thinking that the vals of a key value pair, should only impact the equality value of the thing

Would this structure allow for duplicate keys?

Just like how the key associated with the third item of a vector happens to be 2, but the value is not impacted by the twoness in its vector

otherwise you couldn't conj more than once

associng on an existing key would overwrite it

conjing doesn't take a key, so the next index becomes the key, sotospeak

the map would be implicitly ordered

in the order the structure is constructed

I guess the bigger philosophical question would be, could it be possible to combine the sequential, associative and relational properties into one data structure, such that all mutation functions can operate over that one structure

wouldn't the key for conj operation be a default :smv/nil?

Yes

But if you called key on that nth item, you'd get the number back, I'd think

then what would (assoc (conj (conj #smv "a") "b) :smv/nil "c") produce

well, :smv/nil is suppose to be for internal use, so you can still use nil as a key in your map, if you want

But that could probably be handled more internally

But calling (assoc (conj (conj #smv [] "a") "b") :blah "c") would I think produce:

#smv
[[0 :nilish-thing "a"]
 [1 :nilish-thing "b"]
 [2 :blah "c"]]

but you wouldn't be able to assoc or get the :nilish-thing?

or

#smv
[[0 #smv/nil nil "a"]
 [1 #smv/nil nil "b"]
 [2 #smv/nil nil "c"]]

well, you'd have some internal thing that allowed you to represent when the key should be represented as its index or as the key it's been provided

doesn't matter what the nillish thing is

nor does it have to be exposed

ie. (get *1 nil) on your above example

would that return "a" "b" or "c"

just trying to see where the sequence and mapping semantics might conflict

in the above example, #smv/nil nil would literally mean "no key is here, use the number to the left as the key"

and if you had

#smv
[[0 1   "a"]
 [1 #smv/nil nil "b"]]

so

(get
 [[0 #smv/nil nil "a"]
  [1 nil "b"]
  [2 #smv/nil nil "c"]]
 nil)

An important point of difference when trying to understand where sequence and mapping might conflict... when sequencing a map, it gives you key-value pairs. This gives you only the values, like a sequence would.

But if you call keys on it, you could zipmap it to recreate it

with the seqed vals

seems like values which were inserted using sequence-like conj would then be inaccessible from the mapping-like operations

How so?

what would you get to return "c" in your above example?

either first or #(nth % 0) or (get % 0)... but I would be in error if I assumed "a" should have a named label. Which would rightly trouble your expectations of map-like things.

oh

"c"

I thought you said "a"

so last, etc

It's like a vector where you can give items optional names

yeah, so you couldn't use (get ...) to access it

#(get % 2) => "c"

and if there was a key of 2?

Then that'd be the key of 2

how would you know in advance if an integer key is treated as a key or an index

I think this would complect too many things into one

If it's an integer, it's always the key and index

if I wanted a mapping data structure with a well defined ordering I'd use an (ordered-map)

and fmap from fluokitten does a good job of abstracting maps as containers of their values (instead of kv pairs)

Complect too many things into one... Maybe. That's what I want to know though. Or would having a singular, uni-structure actually simplify things further?

I suppose datoms are sorta like that, or you could use them that way

@john PHP arrays work like that, at once a vector/array and a hash map

Some very “interesting” side effects stem from that. I like Clojure precisely because it mostly avoids the problem, and its collection functions operate on structures in a sane way.

(Modulo clojure.set and contains?)

There is a problem with contains? on Clojure sets?

Thank you @hiredman, @seancorfield and everybody else for the responses on GPL and clojure! Much appreciated and yet another testament to the helpfulness of the community.

A mini rant on accretion not deletion. I've been failing to reify an interface, getting the error message Can't define method not in interfaces: extract. Added the this parameter. Still no luck. Turns out the documentation I was looking at was wrong. And, the interface had a breaking change in the next version! They added a previousTimestamp parameter, and dropped the old method. https://kafka.apache.org/0101/javadoc/org/apache/kafka/streams/processor/TimestampExtractor.html and https://kafka.apache.org/10/javadoc/org/apache/kafka/streams/processor/TimestampExtractor.html </end>

Another interesting datastructure: a map where the keys are sets and associng simply adds a key to a keyset for an existing val. A get would return the val for the keyset-val pair whose keyset contained the passed in key to get. All keysets in a keyset map would have to be distinct though, to ensuring only one val per key.

Though I suppose similar behavior is achieved with nested maps...

Or, alternatively, a keyset map where keysets didn't have to have all distinct elements - just each keyset be unique. Then you could query the keyset map for all vals that include some passed in keyset.

But this idea of treating an associative data structure like a sequential one when provided to a function that normally operates on sequential things, like filter, perhaps the keys associated with the value (if there is one) could be attached to the value as meta data, so the sequencing function still access to the key? Or would it be better to pass values that happen to have keys associated with them as KeyValuePairs when a sequential function runs into them?

otherwise, doing sequential operations on #smv like things would seem lossy, since the seq coming out the other end wouldn't preserve the keys

Or one could just go with Index-Key-Value tri's [i k v] and seq operations just receive something like an IndexedMapEntry that had those three components

But I'm still partial to exploring this idea where keys don't impact the value semantics for the values in an associative data structure

where the structure acts sequential, associative and relational

https://www.youtube.com/watch?v=X_RnO7KSR-4 Love this talk