Neat! I played with it for a bit, and the main issue it saw with it is the trickiness around type names for things like string. For example, to find core or batteries' string split function, you need to search for t -> char -> t list Rather than string -> char -> string list Which finds ocplib's equivalent, and the Core.Std.String.Escaping version as well. Fill on unification doesn't seem ideal, but I wonder if some ability to recognize equivalent type names can be done without full-on search time unification. On Jul 5, 2013 5:12 AM, "Jun Furuse" wrote: > Hi list, > > I have launched a new OCaml API search, OCaml◎Scope at > http://ocamloscope.herokuapp.com . > > OCaml◎Scope is a type directed library search, derived work from OCaml API > Search by Mizuno and its ancestor OCamlBrowser by Garrigue. It is also > inspired from Hoogle, the same API search engine for Haskell by MItchell, > which I regularly use in my Haskell :-) job. > > * Fast and Portable. It loads everything in memory, unlike OCaml API > Search and OCamlBrowser which load compiled interface files (*.cmi) > dynamically. The data file is extracted from compiled files but > self-contained, so the search engine does not require to compile the > libraries locally. > * No use of unification but edit distance of types like Hoogle. > Unification does not provide good results in type directed search, and is > costy. > * OCamlFind and OPAM friendly. OCaml◎Scope knows which items are from > which OCamlFind and OPAM packages. > * OCamlDoc: it also extracts OCamlDoc comments, if possible. > * Small: it can even run as a heroku app. Currently it carries 245k > entries from 76 OCamlFind packages including Core and Batteries, but the > data file (as a marshalled OCaml value) is still 20Mb. > > There are lots of todos but I think the search results look well sane so > far. If you find something strange please drop by > https://bitbucket.org/camlspotter/ocamloscope-server/issues?status=new&status=open and > leave some comments. Thanks! > > Jun Furuse > >