Looks cool! I'm going to mine this for ideas and potentially use it. FWIW 
I've also been implementing some Java functional data structures for my 
language design experiments. 

If anyone is interested happy to share code, my own motivations were:
- I wanted decent persistent Lists, Sets, Maps for language experiments 
without pulling in the whole of Clojure as a dependency
- I care about some operations that are not very efficient in Clojure 
(sublists and concatenation especially)
- It's actually quite a fun challenge writing functional data structures

I have the same annoyance that it isn't easy to play nicely with Clojure 
code unless you implement the Clojure interfaces (IPersistentVector etc.). 
It would be nice if Clojure used protocols so you could extend 
interoperability to arbitrary types, but I can't see any way that is going 
to happen and it probably isn't a good idea overall for performance 
reasons. 

So I agree the practical way forward would be to write Clojure "wrappers" 
that extend IPersistentVector etc. if you want to use bifurcan in Clojure.



On Tuesday, 28 March 2017 00:51:46 UTC+8, 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 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.

Reply via email to