-
Notifications
You must be signed in to change notification settings - Fork 99
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
WIP: Improve unordered-containers API docs. #267
WIP: Improve unordered-containers API docs. #267
Conversation
@sjakobi wdyt about this compared to having separate external docs / tutorial modules? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like this approach!
What's the motivation for shuffling around the complexity annotations though. Doesn't that make the documentation much longer?
@sjakobi made some changes to formatting and added some comments as you suggested.
The complexity of the function isn't the most important thing about the docs, and it feels kinda weird for the docs which describe what the functions do to start with O(something). This also leaves space for commentary on the complexity (see 'HashSet.size' docs) while keeping the formatting consistent. It does make the docs longer, but I don't think optimizing for doc length over organization is the right trade-off. If this looks good to you I can make similar changes to the HashMap documentation. |
Also, switch from bold to emphasis for the complexity clause on the functions at the bottom of the docs. I personally prefer the emphasis instead of bold because it doesn't compete with the function names for attention. |
I haven't really made up my mind about it, but I'd prefer to discuss it separately, i.e. not as a part of this PR.
Which bold complexity clauses does this refer to? |
Sure, I can move them back to being inline.
Complexity: O(n) vs. Complexity: O(n) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like this!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Data/HashSet.hs
Outdated
recommended way to define the instance is using generics, for which you'll need | ||
the @DeriveGeneric@ GHC extension. | ||
|
||
Note: You'll need to enable the @DeviceGeneric@ language extension, either via | ||
@:set -XDeriveGeneric@ in GHCi or @\{\-\# DeriveGeneric \#\-\}@ in your Haskell source | ||
code. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it's slightly unfortunate to go into so much detail here when the canonical documentation on this is in hashable
: http://hackage.haskell.org/package/hashable-1.3.0.0/docs/Data-Hashable.html#g:3
Maybe just add a link?!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No need to add anything. If @m-renaud wants that in the ReadTheDocs stuff, that's his prerogative, but it doesn't belong in the Haddocks.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@treeowl I think the current idea is not to add a ReadTheDocs page, but instead to include some examples and a bit of introductory documentation in the main haddocks.
I think there's some value in including an example of using u-c with custom datatypes, but I mostly feel that it shouldn't duplicate documentation that is or should be in hashable instead…
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, my rationale for including a bit more than a link out was to prevent documentation hops, especially given that u-c is likely one of the first packages that someone new to the language may encounter. It does add a bit more content to the docs but having a full working example in one place without having to piece things together can be very useful.
Additionally, the canonical documentation doesn't mention what to do if you're in ghci, so I thought including it here would be helpful as well for those not familiar with extensions. I don't think we should assume that anyone reading these docs knows that :set -XExtensionName
is how to enable extensions in ghci; yes they're bound to figure it out eventually the more time you spend in the Haskell ecosystem, but one extra sentence to avoid a stackoverflow or reddit post seems like a good trade-off to me.
@sjakobi @treeowl please either 👍 or 👎 this comment:
- 👍 - rationale sounds good, lets leave this
- 👎 - still don't agree, please remove details
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm very happy with the section in its current state.
u-c is likely one of the first packages that someone new to the language may encounter
This is surprising to me! Why do you think new users will encounter it so soon? u-c always seemed fairly niche compared to containers
to me.
I'm a bit torn. I agree with much of your rationale, but I don't we want the u-c Haddocks to become an "introduction to Haskell". Would it make sense to put a full example with very little explanation in the module intro? Maybe. I'm sure we don't want to get into "how to enable extensions in GHCi". That's just far out of scope here. |
@treeowl how's this? |
@sjakobi should I do the HashMap docs in this PR as well or a follow-up? |
Let's make a decision on |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A few more last tweaks.
I think the header docs are really nice now. Good examples, but not too long.
Done. ptal! |
Nearly done, IMHO! Great job! |
Sorry for the delay, updated typeclass references. If there's nothing else I can squash and merge. |
jk, linknig to "Data.Eq.Eq" isn't valid :/ |
It should be |
Note that haddock might still produce a warning since the identifier is not in scope. But it should be able to produce the correct link anyway. Also, please include |
I'll have time this weekend @sjakobi 😄 |
I'll have time this weekend. Eq and Ord linked properly but Hashable didn't for some reason :/ |
@sjakobi at least locally I can't get Hashable to link, any suggestions? |
It actually works for me when I build the documentation with What command did you use? I suspect you maybe just didn't build the haddocks for |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM! :)
Thanks for all the hard work and especially your readiness to find a compromise! 👍
For sure, thanks for the thorough review! I'll squash the commits and wait for the others to review before merging :) |
- More information in introduction (basic operations, and using HashSet with custom data types) - Examples alongside function docs
4d55200
to
08175c1
Compare
Thanks again, @m-renaud! :) |
No problem! Should I do the same for HashMap next? |
This integrates the content from #249 into the module docs themselves instead of having a separate Tutorial module.
Changes: