function search

[kedashoe]

A search box!

• enter text to search function name
• some special chars implemented so far
  • < search input (<int matches functions that take at least 1 int)
  • > search output (>bool matches functions that return a bool)
  • | search input or ouput (|array matches function that either take or return an array)
• all search use a very simple fuzzy search (etr matches "Either")
• can combine (<string >maybe matches functions that take at least 1 string and return a maybe)

other notes..

• the two files that do most of the work are
  • scripts/generate-sig-data - reads the sanctuary README and writes sig-data.js to be used by
  • search.js - does the searching/ui

generate-sig-data depends on HMP, which does not currently handle non-curried functions. This means quite a few sanctuary functions (flip etc) are not searchable yet. Since we are in javascript land, I think it is fair to have HMP handle non-curried functions, so I'll work on that.

I used snabbdom for the ui. More specifically, an unmerged pull request. I think the PR will be merged at some point. Or we can use browserify or something. Not a big deal either way I don't think.

search.js is 100% imperative. I started out use S and R and it was quite slow, of course this was the type checking of S which I did not immediately realize. Played around with things for a bit, I don't have the old code but I wrote down some numbers just for kicks.

searching through 113 item array with a function built using

• S.pipe, with type checking: 6000+ ms
• S.pipe w/o type checking: 1-10 ms
• R.pipe: 0.5 ms
• imperative: 0.25 ms

other other notes..

• how to search for nested types eg maybe int. probably can just concat all text for a given argument and fuzzy search that for very good results
• searching for function arguments.. probably could make this work quite nicely by include arrows in concatenated text (eg search for -a->b or something like that)
• can't currently search constraints, but should be easy to add
• ui was basically just to get this POC working, can certainly be improved (search box follows page as you scroll around, maybe provide a list of all functions along the right, etc etc)

Let me know what you guys think of it so far

[davidchambers]

This is very exciting to see!

I'm sorry that I've been slow to respond. I'm preparing to move to Europe and haven't had reliable internet access for the past few days. This should not be a problem from Wednesday.

I'm not keen on the <input/>output notation. I'd like to be able to leverage my existing knowledge of Hindley–Milner type signatures, as Hoogle lets me do. I'd like to be able to enter String -> to find functions which take a string argument, or -> String for functions which return a string.

Is there a reason to favour the <input/>output notation over HM-like notation?

Searching by type-class constraints would be quite useful, I think. I'm imagining entering Ord a => to find all the functions which operate on values of ordered types.

[kedashoe]

I've not had great success with hoogle so I wasn't really motivated to mimic it. I think this might have more to do with what hoogle is searching than how (eg I could not find readMaybe by searching for its exact signature in hoogle but found it via google.. maybe just too new for hoogle?). Also I'm sure it has quite a bit to do with my limited haskell knowledge/experience :p

Is there a way to search hoogle for input type String and output type Int and limit it to things that actually return an Int? String -> Int also matches a function with signature String -> Int -> Bool etc? I feel like this is my most common search so that was maybe the main reason I took this approach. hoogle seems to return anything and everything that matches at all. As long as it sorts things well, I guess that is a nice feature.

Thought it would be interesting to try something else but I guess everyone would probably prefer hoogle for sanctuary.

[davidchambers]

I'd love to see this pull request revived after we merge #13.

One option is to filter the table of contents itself. Consider this simplified table of contents:

• API
  • RegExp
    • regex :: RegexFlags -> String -> RegExp
    • regexEscape :: String -> String
    • test :: RegExp -> String -> Boolean
    • match :: RegExp -> String -> Maybe (Array (Maybe String))
  • String
    • toUpper :: String -> String
    • toLower :: String -> String

Were we asked to search for every function with RegExp in its signature (setting aside the question of how such a query would be written), we'd keep all the matching list items and all their ancestors:

• API
  • RegExp
    • regex :: RegexFlags -> String -> RegExp
    • test :: RegExp -> String -> Boolean
    • match :: RegExp -> String -> Maybe (Array (Maybe String))

There are really three issues to consider:

• How should the results be displayed? (The suggestion above is just an idea.)
• How should the results be sorted?
• How should queries be written?

You've noted some real limitations of Hoogle, @kedashoe. I wonder, though, whether it's possible to have more control over the search results without abandoning the familiar Hindley–Milner notation. We could, for example, provide an Exact matches only checkbox:

Search term: [ Quux -> Quux _______ ]
[ ] Exact matches only

Results:
- foo :: String -> Quux -> Quux
- bar :: Quux -> Quux
- baz :: Quux -> Quux -> Boolean

Search term: [ Quux -> Quux _______ ]
[x] Exact matches only

Results:
- bar :: Quux -> Quux

We could split Exact matches only into Starts with and Ends with if desired:

Search term: [ Quux -> Quux _______ ]
[x] Starts with
[ ] Ends with

Results:
- bar :: Quux -> Quux
- baz :: Quux -> Quux -> Boolean

Search term: [ Quux -> Quux _______ ]
[ ] Starts with
[x] Ends with

Results:
- foo :: String -> Quux -> Quux
- bar :: Quux -> Quux

This approach seems flexible. We could, for example, include an Accept similar types checkbox to allow a search for Number -> Number to find negate :: ValidNumber -> ValidNumber.

[kedashoe]

I wonder, though, whether it's possible to have more control over the search results without abandoning the familiar Hindley–Milner notation.

I will switch gears and go with HM for the search format. I'm sure we can come up with ways to extend it if we feel the need :)

[kedashoe]

superseded by #23