-
Notifications
You must be signed in to change notification settings - Fork 21
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Hello #6
Comments
Hi, thank you for the feedback, I love this cross-pollination! I'm busy now optimizing prelude's vector in some cases where your list bests it too :-) especially map & concat, maybe others and also it causes me to reconsider how to iterate over items in the vector. Anyway, super interesting and tons of fun, a shame time is so limited. Regarding the non-empty vector. Actually in the blog post I mention prelude already has a non-empty linked list, ConsLinkedList and give that example: if (!myLinkedList.isEmpty()) {
return myLinkedList.last().get();
} where Vector can only achieve: if (!myVector.isEmpty()) {
return myVector.last().getOrThrow();
} With the Now, the annoyance... If you have three options... [option1, option2, option3]. This is Option[]. No problem. But now if the first one is somehow a Some. And the other two are only Option... Then you get a compile error... Can't put an Option in a Some array. For that reason I added on Option a method toOption(). Meant to transform Some & None to Option. Same on linkedlist and stream. It can make sense to have this ability as a programmer to say "this function only accepts non-empty lists", depending on the function, also as a documentation feature. But I'm not taking advantage of this much in prelude because I want to support javascript users. Many libraries and languages offer a non-empty list/vector, it certainly cannot hurt, and if a team is diligent about using them, I'm sure they can be a real plus, but I'm not sure they're so important as to invest lots of energy into them for typescript which is still a little weak in its type-system. I actually stumbled almost without trying on a way to get them almost for free for linkedlist (and stream), because that's just the way linkedlist works... (a node is cons.. or empty...) So my current way of thinking is... If you care about that as a prelude user, you can use LinkedList. If you don't care much about that, you'll get better performance with Vector. I didn't come up with a way to get non-empty vectors in prelude in a low-overhead and not-complicating way for now, but I'm keeping an open mind on the issue. But I have no plans on implementing them for now. |
since the title of the issue is "hello" maybe I'm not off-topic here by asking this now. I've been looking at the implementations of prepend & append in your list library. Very very neat trick with comparing the prefix & suffix length with a value stored in the vector to allow for concurrent append/prepend without eagerly duplicating the prefix & suffix! I think I'll steal this from you ;-) however to give credit, i'm wondering, did you come up with that idea (together with the idea of storing these lengths with the depth in a single number, pretty cool as well), or if this from some paper or something like that? |
Slow response here 😓 I've been busy with my exams and catching up afterward.
Me too 😄 Thank you for sharing your thoughts with regards to non-empty structures. The way I have considered adding non-empty list is to do it completely at the type-level with no differences at run-time. To see what I mean look at this internal type type NonEmptyList<A> = List<A> & { "nonEmpty": true }; The function last<A>(l: NonEmptyList<A>): A;
function last<A>(l: List<A>): A | undefined; What do you think about that? It seems to me that it would add extra type safe-type and
That sounds weird to me. I think that TypeScript should be able to handle that correctly as long as
Not at all 😄
The idea of storing some elements in both ends (what I call prefix and suffix) is not my own. It's described here for instance. The trick where List stores the length of the affixes separately and use it to avoid duplicating them it is my own idea 😊 I'm happy to hear that you like it. It does make The trick where several integers are stored in a single bit field is not my own. I read about it at some point in this article by the author of Bluebird. I'm sure the idea proceeds that article though. It's supposed to reduce the allocation cost and memory usage. From my benchmarks, it did make a difference but definitely not a huge one. |
Hello @emmanueltouzery. Congratulations on a very nice looking library! 👍 I recently stumbled upon it and found it to be very interesting.
As you're aware I've created a library with an immutable list. I saw the really clever type you have for
partition
. I've just implemented it here. Thanks a lot for sharing the idea in your blog post!I see that you've added List to your benchmarks 😄 I had already done so myself to see how the libraries compare. I'm going to work on improving performance in the cases where List is not as fast as your Vector.
I can see that you have "Non-empty vector?" on the "Wishlist/upcoming features". I have been thinking about adding such a feature to List. But, I'm now sure if it's worth it. What do you think? When does the feature help?
The text was updated successfully, but these errors were encountered: