Fork me on GitHub
#clojure-dev
<
2019-08-13
>
andy.fingerhut21:08:13

So it looks like there is a Tuple class in Clojure's source from 2015, but it currently has no constructors, and is used in only a handful of places in the compiler to create objects with class PersistentVector. There is a comment saying it was proposed by Zach Tellman, which I am guessing was related to the CLJ-1517 "unrolled small vectors" ticket that ended up not providing the performance gains that were initially hoped for. But I guess the Tuple class remained in this kind of vestigial form?

ghadi21:08:34

the constructors are still useful

ghadi21:08:10

without Tuple.create(a, b, c) all the call sites had to generate an array and pass that to PersistentVector.create(Object...)

andy.fingerhut21:08:20

Only reason I am curious is that I am tracking down core.rrb-vector library JIRA tickets, to see which ones need work, and which might be closable as obsolete. One is related to objects with class Tuple, from Clojure 1.8.0-alpha2, and I will check soon, but suspect at that time there was a Tuple constructor.

ghadi21:08:50

Map.of(k1, v1, k2, v2) would be useful as well, but doesn't exist

andy.fingerhut21:08:11

I mean constructor here in the sense of a Java constructor with the name Tuple, which doesn't appear to exist now.

ghadi21:08:02

yup, that's all correct AFAIK

andy.fingerhut21:08:09

Hmm. And apparently didn't even exist in Clojure 1.8.0-alpha2 when the ticket I am looking at was created for, although the Tuple class did temporarily have quite a few more methods at that time.

ghadi21:08:03

seems like an issue that can be closed, if it's filed against an alpha

andy.fingerhut21:08:08

Oh, I see. The issue I'm looking at mentions these classes T0, T1, etc. for small vectors/tuples. Those were eliminated since 1.8.0-alpha2.

andy.fingerhut21:08:43

Yep, looks very safe to close. I just feel better closing things when I'm more sure of the reasons involved for the issue being created in the first place.

ghadi21:08:03

Java added List.of(a) of(a, b) of(a,b,c) in 11, for similar reasons

ghadi21:08:31

afaik they do only size specialization for 0/1, not 0/1/2/3/4/5/6

ghadi21:08:32

jshell> List.of("a").getClass()
$4 ==> class java.util.ImmutableCollections$List12

jshell> List.of("a","b").getClass()
$5 ==> class java.util.ImmutableCollections$List12

jshell> List.of("a","b","c").getClass()
$6 ==> class java.util.ImmutableCollections$ListN
1/2 rather

andy.fingerhut21:08:54

Thanks for confirmation!

andy.fingerhut21:08:54

I believe I am getting close to a semi-magical day when all core.rrb-vector open issues are resolved, and incidentally, the library crashes in far fewer situations (hopefully none, but I doubt that will be the case).

ghadi21:08:48

thank you for maintaining it @andy.fingerhut HERO

andy.fingerhut21:08:20

My OCD kicked in, and I have long wanted to take it on as a hobby project to figure out how it worked. I just confirmed I do have fixes for all open issues, although for one of them my current 'fix' is kind of a little bit of a cheat, where concatenating two vectors will often run in O(log N) time, but then it does a quick sanity check on the result, and if the tree is getting unbalanced, I punted and did the slow O(N) concatenate (but very reliable and well tested).

andy.fingerhut21:08:38

It is still future work to make it always O(log N), but in the mean time at least it won't crash.