Open sjakobi opened 8 years ago
Thanks for your contribution, however I believe it would be better for you to release this as your own separate package. Since in your implementation you only depend on the public parts of the API this should pose no problems for you.
I've actually been thinking about revising the library to extract all the others containers as separate packages. If you're interested in the reasons, I've described a few in a documentation for another package. I plan to make an expanded post about the benefits of such an approach some time soon.
Thanks for the quick response!
I think you're making some pretty good points in that README. On the other hand it's only a few days ago that I heard other people favoring fewer, more fully-featured packages. I think the main argument was less maintenance hassle for both authors and users.
Would you mind if I leave this PR open until the discussion on your post is over? I'd be very interested in hearing other opinions on this policy.
Sure. I'll try to remember to post a link here when I publish it.
Sure.
Thanks!
I'll try to remember to post a link here when I publish it.
No worries! I'm sure I'll see it on r/haskell
! :)
@nikita-volkov Did you ever write that post? ;)
@sjakobi What ever became of this? Did you release your work as a separate package?
Did you release your work as a separate package?
I haven't so far. If you'd like to use it, I will though! Do you have a comment on the design issue from above?
Should the counts be represented as Word, Word64 or Natural instead?
@3noch Not yet
I'd just like to chime in on the separate package debate. The major problem I see with releasing a package like stm-containers-multiset
is discoverability.
Ideallly, there could be a prominent section in stm-containers
' description that says, like, "Check out these similar packages, none of which are officially endorsed by this author". Then, even crappy packages/variations can at least get enough eyes on them for collaboration, bug fixes, rewrites, or what have you. It'd just be a shame if multiple people implement stm-containers-multiset
just because they don't know about each others' work, and the Hackage UI really does not help us out here.
@nikita-volkov What do you think about that? Would you be willing to, say, point at other peoples' packages in the stm-containers
description, for situations like this? (If not, totally fine of course, just wondering).
@sjakobi Natural
:)
(Similar situation solved in stm
with Natural
: https://hackage.haskell.org/package/stm-2.5.0.0/docs/Control-Concurrent-STM-TBQueue.html)
Would you be willing to, say, point at other peoples' packages in the stm-containers description, for situations like this?
Sure! No problem
I have implemented a simple multiset on top of
Map
that is useful for counting things. The API is partly inspired by themultiset
package.I'm still unsure about the following design issue:
Should the counts be represented as
Word
,Word64
orNatural
instead?This would simplify
focus
,insertMany
anddeleteMany
, and allow for larger counts.On the downside
Word
andWord64
are slightly more hairy to use safely andNatural
would result in higher memory consumption.