To be clear, my intention was always to wrap the implementations in the appropriate Clojure interfaces, and I don't believe that will cause much, if any, of a performance hit (inlining is magic). However, there are some real questions regarding how to expose non-standard equality semantics, and whether transients should be represented using the immutable or mutable collection variants.
For what it's worth, I have about 1/3 of an implementation of Clojure-compatible versions of these data structures, I just wanted to mull on the above questions a bit before going further. I'm happy to discuss them here in more depth if you have any questions or opinions. Zach On Tue, Apr 18, 2017 at 6:53 AM Dave Dixon <dave.d.di...@gmail.com> wrote: > Stared at this a bit yesterday. Seems like if you want to leverage spec > while using bifurcan, then the bifurcan types need to have the Clojure > wrapper. The alternative appears to be re-implementing at least a large > subset of collection-related spec code, which is a lot to bite off. Also > tried updating some existing code to use bifurcan. Similar to spec, there > are going to be cases which are less perf sensitive, where it would be nice > to use code that is polymorphic for collections, and drop down to the fast > interface in perf-sensitive parts. > > > On Monday, April 17, 2017 at 1:52:39 PM UTC-7, Dave Dixon wrote: >> >> What is the issue with wrapping in Clojure interfaces? Added overhead of >> function calls? >> >> I'm finding myself in the process of doing some of this, at least for >> constructors. Also thinking of generating predicates/generators for use >> with spec. >> >> On Monday, March 27, 2017 at 9:51:46 AM UTC-7, Zach Tellman wrote: >> >>> This is a slightly irregular announcement, because it's not for a >>> Clojure library. Rather, it's for a library written purely in Java: >>> https://github.com/lacuna/bifurcan. >>> >>> This is a collection of mutable and immutable data structures, designed >>> to address some of my personal frustrations with what's available in the >>> Clojure and Java ecosystems. Notably, they have pluggable equality >>> semantics, so while they *can* use Clojure's expensive hash and equality >>> checks, they don't *have* to. They also provide high-performance mutable >>> variants of the data structure which share an API with their immutable >>> cousins. >>> >>> I'm posting it here to ask for people's thoughts on how, if at all, this >>> should be exposed as a Clojure library. It would be simple to simply wrap >>> them in the Clojure interfaces and make them behave identically to >>> Clojure's own data structures, but that kind of obviates the point. >>> However, creating an entirely new set of accessors means that we can't >>> leverage Clojure's standard library. >>> >>> It's possible that I'm alone in my frustrations, and no Clojure wrapper >>> is necessary. But if this does solve a problem you have, I'd like to hear >>> more about what it is, and how you think Bifurcan might help. Please feel >>> free to reply here, or to grab me at Clojure/West and talk about it there. >>> >>> Thanks in advance, >>> Zach >>> >> -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to a topic in the > Google Groups "Clojure" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/clojure/1m_I7IrDGb0/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.