Add to Pursuit?

[rintcius]

Is it an idea to publish this lib to Pursuit?

(BTW I'm planning to upgrade this lib to purescript 0.10, so maybe this can be done after that?)

[jplatte]

Oh, certainly did not expect to see this library getting any attention anymore. It's not really done, otherwise it would be on bower and pursuit. Some way through fiddling with this I learned about Cofree and how it actually does pretty much all I wanted. I might see if I can create a PR with most of the utility functions from this library for purescript-free that has the Cofree type, because IIRC those are really the only thing that package doesn't have to be usable in the way I wanted to have this library be usable.

[rintcius]

Ah right. Personally I don't mind to upload it in this state (it looks usable for my use case and can add more in case someone needs it). I was just googling around for rose trees and this seems to be the only purescript lib so thought to go from here. Regarding "certainly did not expect to see this library getting any attention anymore" do you mean there are other, more complete alternatives that I have missed?

CoFree stuff being added would be awesome but it's not necessary for my use case at this moment.

[jplatte]

CoFree stuff being added would be awesome but it's not necessary for my use case at this moment.

I'm not talking about adding anything to this library, what I'm saying is that you can use CoFree as a tree structure. For example a strict rose tree would be CoFree Array.

[parsonsmatt]

An upside of Cofree representation is that you can make trees that are polymorphic in the subtree representation. Cofree Array is great for doing a lot of reads, but probably sucks performance-wise for heavy updates. Whereas Cofree (Map Int) is going to have better updates, at the cost of O(lg n) lookups.

This branch never ended up getting merged, though I think it offers a nice interface to trees generally.

[rintcius]

Pretty neat stuff! Do you guys think there's still value in keeping the direct representation that is already there? I quite like these representations in terms of CoFree but there may be value in keeping the direct representations too, in the same way as usually the direct representation of e.g.Free Monoid is also kept via List.

[jplatte]

I really don't know. I just started this project because I needed something like it. I'm not really experienced enough with purely functional programming languages to be designing APIs.. So I think the best way forward is for this library to move ownership, and the new owner deciding what to do.

@parsonsmatt Considering you did 99% of the work in the cofree-tree branch, would you be up for taking over this library / repo?

[parsonsmatt]

@rintcius So -- the different direct encodings have very different performance properties for different application, and just having data Tree a = Tree a (Array (Tree a)) would imo be unnecessarily limiting. Wouldn't it suck if array update ended up eating a ton of time/space in your app, and you had to recode around a different tree structure?

Here's what I'd want to do before "completing" the library:

1. Decide on a pleasant API to use. Ideally this API would be generic across tree-like structures. The one present in the branch now is probably fine, but I'd want to investigate alternative with the updates to psc.
2. Write benchotron benchmarks for the different representations, with the "best average" performing one being the one exported by default from Data.Tree, and easy type aliases exported from other modules.

Since I guess I have Opinions about all of this stuff, I don't mind taking the repo over @jplatte 😄

[jplatte]

@parsonsmatt Thanks! I can't currently transfer ownership though as you still have a fork with the same name under your profile.

[parsonsmatt]

I deleted it, should be good to go. Thanks! Matt Parsons

…

On Mon, Dec 26, 2016 at 9:04 AM, Jonas Platte ***@***.***> wrote: @parsonsmatt <https://github.com/parsonsmatt> Thanks! I can't currently transfer ownership though as you still have a fork with the same name under your profile. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#9 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AG-LIOCdrcBY4R_p_Aag0J1FhXneRLHBks5rL8l3gaJpZM4LTJmm> .

[rintcius]

@parsonsmatt Sure you have to select the best matching data structure, but that's not different than choosing between e.g. Array or List in purescript.

Good idea to have the different representations benchmarked. I'd be surprised to see CoFree having particularly good runtime characteristics though. In my mind they're good from a modelling perspective (like you say as well), but there's a penalty during runtime.

Anyway, going CoFree should be ok for my use case as well & I'm quite interested to see the implementation and a benchmark between the different representations!

[maackle]

If there are no plans to do anything with this library, would you consider putting a message in the readme explaining to the reader that Cofree (Array | List) a is exactly a rose tree so you might as well just use that? This is really valuable knowledge for a beginner like myself, and if I hadn't made it to this issue page I might be forking this repo and using the explicit tree structure in master.

I'm now attempting to use Cofree directly for my tree structure (still wrapping my head around explore though).

[parsonsmatt]

I've been holding off on any PureScript work until the compiler hits 1.0. I'd be happy to include a note in the README if you'd like to make a patch.