ndmitchell
commented
10 years ago My plan for Hoogle 5 is to switch to a rich JSON API, then a thicker client which does type ahead, completions, colorings etc. It sounds like you're already doing that, which is awesome! My vague plan (and ordering) was:
- Redo the databases and generation, which I'm doing on the "hoogle5" branch already, maintaining roughly the same Haskell API as currently (but not quite).
- Improve the JSON API to include all the data based on the Haskell API.
- Write a rich front end on top of the JSON.
If you have enough information to write a "slightly hacky" rich front end, which I can then tidy up in step 2, that would be awesome. If you find information missing, I'll circle back and improve the JSON API against the current branch before continuing with hoogle5. From what you are describing, I'm hoping you'll finish the rich front end on top of JSON before I get to it :)
While making a custom template for a more Dash-like web UI for Hoogle I noticed the data provided by the JSON API is fairly aggregated. Most notably the name of things (e.g. fold, hoogle, ...) and the kind of things (function, package, ...) are not available separately but mixed together into 'self'
It would be nice if all the data were available before aggregation (I'm assuming name and e.g. 'package' are actually stored separately.) While it's not terribly difficult to reverse engineer the name and the kind from the single field it seems somewhat wrong, an API should provide data in a form that does not require parsing and guessing on caller side IMO.