[ANN] docs.ocaml.pro : an OCaml Documentation Hub

Great ant very needed initiative.
A production-ready Hoogle for OCaml is something we were missing for many years.

I just did a search by type signature:
'a → 'a

It did not return anything. I hope we can make such searches in the near future! :slight_smile:

2 Likes

It’s not quite the same as hoogle, but merlin has a functionality to search for functions by type signature - the feature doesn’t seem to get much attention apparently - probably the interface is a little lacking, but with some extra elisp tuning, it can work quite smoothly:
merlin-search

5 Likes

The command line for this:

ocamlmerlin single search-by-polarity -position 0 -query '-int +string'

(To search for values of type int -> string.)

2 Likes

Late to the party, but I want to add that it’s not just that this seems incredibly convenient for people who are already using OCaml. It’s the sort of thing that makes the thought of learning a new, unfamiliar language more welcoming, and less forbidding. I think a friendly interface to resources can make learning and using a language easier–both practically and psychologically.

3 Likes

Indeed, this is an early version of the site. We hope that the site will indeed evolve in this direction: we will progressively add multiple versions for every package, and since we already have the opam description for every package, the site should at some point become a super set of the opam-packages website. Yet, there is a lot of work to reach this point, we need to both improve the quality of the documentation, of the interface, and then be able to track changes on opam-repository to generate documentation for new packages… It’s a long path ahead :slight_smile:

2 Likes

Great, thanks for this site.

Is there a reason why for example unison and planets are not listed in the chain of dependencies?

They are not listed at all because the switch we created to build this documentation did not contain them, there might have been some incompatibilities in the versions of some common dependencies that prevented them from being built in such a maximal switch. We hope to be able soon to have all packages by creating switches for every package instead of using maximal switches.

Joining the chorus, fantastic work! I’ve been looking forward to such a site being available for OCaml documentation.

My goto package for brilliant documentation is lwt and it looks great. Some of my packages in the aws space need more work to match that.

Some suggestions (perhaps already mentioned still reading the whole thread):

  • link to the source code for a function/type
  • lwt lists some surprising files in Packaged Files eg dlllwt_unix_stubs.so, cmx/cmti/cmt/cmi
  • some of the relative links in lwt docs like Tutorial don’t seem to work in Safari Lwt (LIBRARY.lwt@lwt.5.4.0.Lwt)
  • Support for multiple versions of the same library eg lwt 5, 6, etc and being able to swap between the two. Also include the CHANGELOG if that’s available for a library. Assume this will be added in time.
  • How do you package up a pure documenation module? Right now lwt seems to include it inline in the lwt.mli file and an index.mld. In general a good source on how to nicely document a library, I’ve gathered a few links to libraries that do it well like lwt. Are there other resources?
1 Like

Yes please, production ready Hoogle for OCaml would be great. I use it all the time in Haskell, built on an index of my locally installed libraries and source code.

1 Like

From the package page (e.g. index (OPAM.alcotest.1.3.0.index)), it’d be nice if there was a super clear “Read the docs” button or link somewhere. Right now you just kind of have to know to click on the module name under “Package modules”, which isn’t very intuitive.

1 Like

I agree with the diagnostic (i.e. the interesting bits are hard to find) but disagree with the solution. I think that from a user perspective the presentation order is wrong: show what most user are interested in first (i.e. manuals and api docs). If you do so then there’s no need for additional UI bureaucracy and user clicks.

In odig (same package, other package with a custom index.mld file), package metadata, which you are most of the time not interested in is relegated to the end of the page (except for a few elements which are integrated directly in the package title).

4 Likes

That’s a reasonable point. I was imagining something like what docs.rs has for Rust docs with a big “Documentation” button that’s hard to miss.

Indeed, there’s a big button there !

But I rather see this as the manifestation of a bad design in their information structure (I’m actually quite confused by that page which seems to have documentation both on that page and other bits when you follow the button).

If you can provide the same experience with one less click (and I think odig proves we can) you should go for it.

Indeed, we will change the layout of these pages, so that it becomes easier to enter the documentation. There are also some fields that are not yet displayed, though they are known by the tool (like the link to the source archive or applied patches).

1 Like

Yes, it would make more sense to have a page with all of the documentation, with a big button on that same page that links back to the very same page. You would never get lost with that sort of recursion.
:slight_smile:

1 Like