Thanks! That's a reasonable suggestion. Actually the "Internal" module name was left there because we decided to export all implementation at the last moment. We've spent quite a lot of time working on benchmarks. Now you can find those which was ran on my laptop right in the github repo [1]. Although this kind of setting (I mean 4 capabilities) may not be the desired environment for STM-based algorithms. I believe we'll provide plots for machines with more capabilities in due course. Probably I had to include link to benchmarks into haddock package documentation. [1] https://github.com/Alllex/stm-data-collection/blob/master/charts/charts.pdf Thanks for your reply. On 22.10.2015 20:42, Felipe Lessa wrote:
A suggestion after looking at the API docs:
Usually modules called "Internal" are not meant to be used by the user of the library unless they really know what they're doing. However, the description of the package says that I should choose the implementation that suits my needs, so these aren't "Internal" modules after all. Also, they don't export anything that I would qualify as internal, such as data type constructors and helper functions.
I'd suggest either renaming the "Internal" portion of the hierarchy to something else (such as "Impl") or dropping it completely (i.e., leaving the implementation modules on the same level as the "Class" modules).
Everything else looks quite good! An advanced request would be having benchmarks showing which implementation is best for which use cases, esp. for [ALPRST]*SLPQ, but that's non-trivial.
Cheers, :)