1015007 - Search API based on type signature (and morphisms of the type signature)

Status: RESOLVED WONTFIX

(Webtools Graveyard :: DXR, defect)

Description

[Marcell V.C]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:29.0) Gecko/20100101 Firefox/29.0 (Beta/Release)
Build ID: 20140514164129

Steps to reproduce:

Used Hoogle (http://www.haskell.org/hoogle/)


Actual results:

Loved the type based search features: (a -> b) -> [a] -> [b] returns things like map... which is nice... 


Expected results:

I should have thought to myself "Oh DXR has this feature! I can search for a function with input Foo and output Bar and get all the functions that do that.

List of example queries:
* -> foobar   ; returns all the functions that return foobar
int -> foobar  ; returns all the functions that go from an int to foobar
foobar -> *    ; returns all the functions that take a foobar

It'd also be nice to get fuzzy searches on types.

Comment 1

[Marcell V.C]

This slide decks go over alot of the motivations and implementation details:
http://community.haskell.org/~ndm/downloads/slides-hoogle_finding_functions_from_types-16_may_2011.pdf

I think a language like C can easily modeled by thinking of all the types as being implicitly curried:
int foo(char c, bool v) is ~equiv to (char, bool) -> int which is an isomorphism of char -> bool -> int

Comment 2

[Erik Rose [:erik][:erikrose]]

1. What kind of fuzzy matching would you find useful? I was just trying to decide this morning whether we'd want prefix searches on types or what, ideally. (Obviously, we'd at least want to be able to opt out of prefix searching as needed.)

2. Are you talking about currying for the sake of indexing or actually presenting it that way in the UI? I think a C programmer would expect to type something like (char, bool) -> int, at least for C code.

Comment 3

[Marcell V.C]

1. What I ment by fuzzy matching are things like:
    - int -> char -> int   is kinda like   int -> int -> char -> int
    - I.e. there is some structural edit distance that is explored

2. I agree the C programmer would probably expect (a, b, ...) -> c. I think internally though its easiest to represent it in a normative form. There are a few reasons why I think uncurrying here would help.
    - It lets us avoid specializing to C like code
    - We might be able to leverage the large amounts of work done on Hoogle
    - If the language we were indexing supported tuples in the types:
        + (a, (b,c)) -> d is kinda like (a,b,c) -> d which is kinda like a -> b -> c -> d
    - inputs and outputs are treated more or less the same so the structural edit code would apply to both

Eitherway, I think then the C plugin or w/e should then output things of the form (a,b,c,..) -> d and only take in things of a similar form

Comment 4

[Sylvestre Ledru [:Sylvestre]]

DXR is no longer available. Searchfox is now replacing it.
See meta bug 1669906 & https://groups.google.com/g/mozilla.dev.platform/c/jDRjrq3l-CY for more details.