Proposal: Add a convenience method for "unpacking"...

# language-proposals

[gregorbg]

Proposal: Add a convenience method for "unpacking" lists the functional way, i.e. like linked lists with a head element and the remaining tail elements.

fun <T> List<T>.headWithTail() = firstOrNull() to drop(1)

Obviously the function still needs a better name, but I find myself using this concept rather often when recursively processing list entries or working with data that is presented as a "heading + contents" table.

val (heading, contents) = parsedCsv.headWithTail()

[jw]

this isn't a language feature, it would be a #stdlib proposal

[elizarov]

Also, this would make all your algos O(N^2), which would be a nasty surprise for people who are new to Kotlin. I’d reserve it only for people who understand how it works inside and its limitations, i.e. for people who can write that kind of function in their code as needed. For novices, I’d rather teach them writing recursion with indices for better performance.

[stantronic]

Would you not want a dedicated collection class for this kind of approach?

[jimn]

https://en.wikipedia.org/wiki/CAR_and_CDR this is ancient and found in a ton of legacy. not exactly a java 101 topic but can (at whatever O notation effects) enable significant code parsimony for certain solutions.

[elizarov]

It is indeed legacy from the times when computers worked with linked data structures and the same speed as with arrays. Nowdays the former is orders of magnitude slower and thus is usually avoided in any kind of serious production code. Sadly, linked structures and CAR/CDR are still being taugh sometimes without teaching students about all the downsides. Education is very conservative and slow to catch up.

[jimn]

i don't feel like stdlib or kotlin is the right place, but this is inescapably bound to gofai era designs and knowledge representation particularly subsumption architectures. i was coding for 15 years before i encountered this the first time in cyc codebase.

[jimn]

CAr/CDR is still relevant to consider non-desktop applications like clockless and hellbent low-power designs https://www.rs-online.com/designspark/hands-on-with-a-144-core-processor

[elizarov]

I’m not saying it’s not relevant. I’m saying it is much less useful than it used to be, given a serious speed handicap on a typical modern processor. Since a lot of people are not aware of that, but are still being taught, it is wrong to support it out of the box in the stdlib of the modern language. For those rare cases when you really need it (where benefits outweight) you can always implement it yourself with a few lines of code (really easy in a language like Kotlin).

[elizarov]

For example, there is an anecdotal evidence that if you take a typical average-quality Java Enterprise app and search/repace LinkedList with ArrayList, you’ll get an overall speed boost and lower memory consumption. The very act of adding LinkedList to Java standard library was a mistake.

[jimn]

i would write my own slist and stack in lockless async code for NIO buffer decoding. everything in jdk collections and by transitive property kotlin stdlib is a little heavier than it might otherise be if written inline. List vtable has just a few extra method that aren't always common.

[jimn]

the jury is out whether an array of one is faster than a singly linked list node.

[jimn]

The Kotlin community could benefit from the Rope abstraction or the javolution Text which is not hugely different.