search #23

kedashoe · 2017-01-30T06:26:54Z

Supersedes #11. Now using hindley milner notation for the search input. Things seem to be working pretty well?

I've brought in browserify to tie in external packages and uglify to minify. I don't really know anything about minification, so if anyone has some thoughts there I am happy to go with something else for that step.

One kinda funny thing: you can't search for combinators by name because the input parser does not allow function names (correctly, I believe?) to start with upper case letters. We could probably create an exception for them.

Todo:

lint src/search.js
properly index type variables (so that eg x -> x matches a -> a)
fuzzy matching too many results?
update query string at /search/ as input changes
parse query string to populate search field
add search field to / which redirects to /search/?q=…

davidchambers · 2017-01-30T10:40:48Z

Very cool, Kevin!

I'm sure I'll have more thoughts, but these are my initial ones:

When searching, I expect the list of results to contain only matches and their ancestors. "Overview", for example, need never appear in the list of results.
Either a b produces many matches, but Either x y produces none. This suggest that we're not treating type variables as variables. a -> a and x -> x should both match S.I.
Maybe#map produces many matches for some reason.

kedashoe · 2017-01-30T17:39:05Z

When searching, I expect the list of results to contain only matches and their ancestors. "Overview", for example, need never appear in the list of results.

makes sense

Either a b produces many matches, but Either x y produces none. This suggest that we're not treating type variables as variables. a -> a and x -> x should both match S.I

ya, should have mentioned this one

Maybe#map produces many matches for some reason.

I think I am letting the fuzzy searcher be too generous? Will play around with it.

davidchambers · 2017-01-30T17:56:12Z

Having given the matter more thought I now believe the search functionality should have its own URL:

https://sanctuary.js.org/search/

We could then share links to search results which would be useful. For example:

https://sanctuary.js.org/search/?q=List%20a%20-%3E%20Maybe%20a

We could make this discoverable by including a text input near the top of the main page (as you have currently), and setting window.location to the appropriate value when a query is submitted.

kedashoe · 2017-02-10T23:11:11Z

Pushed an update. The search now manages its own list rather than showing/hiding items in the ToC (didn't occur to me at first, but this was always going to be necessary). x -> Maybe y should now return appropriate results. Do you want the URL stuff to be part of this PR?

davidchambers · 2017-02-11T00:22:25Z

Pushed an update.

Looks good!

x -> Maybe y should now return appropriate results.

I see these results:

Maybe#ap :: Maybe (a -> b) ~> Maybe a -> Maybe b
Maybe#chain :: Maybe a ~> (a -> Maybe b) -> Maybe b
Maybe#equals :: Maybe a ~> b -> Boolean
Maybe#of :: Maybe a ~> b -> Maybe b
Maybe#reduce :: Maybe a ~> ((b, a) -> b) -> b -> b
maybe :: b -> (a -> b) -> Maybe a -> b
encase :: (a -> b) -> a -> Maybe b
maybeToEither :: a -> Maybe b -> Either a b
eitherToMaybe :: Either a b -> Maybe b

The results in bold seem out of place to me.

Do you want the URL stuff to be part of this PR?

Yes please! Let me know if I can help with this in any way. :)

kedashoe · 2017-02-11T00:50:17Z

ah, forgot to mention that. In order to allow us to find functions and methods, I am compiling methods to their function equivalent. So

:: Maybe a ~> b -> Boolean

is compiled to

:: t0 -> Maybe t1 -> Boolean

https://github.com/kedashoe/hindley-milner-search/blob/master/src/hm-search.js#L68-L78

davidchambers · 2017-02-11T00:55:38Z

I am compiling methods to their function equivalent

It might be nice for ~> to return all methods, and for Maybe a ~> to return all Maybe methods. It's worth reconsidering your rewrite rule.

By the way, I'm quite confused by the results that ~> currently returns!

kedashoe · 2017-02-11T22:36:38Z

It might be nice for ~> to return all methods, and for Maybe a ~> to return all Maybe methods. It's worth reconsidering your rewrite rule.

I had thought we were trying to discourage the use of methods? The difficulty is that I think we definitely want Maybe a -> b to return methods if they match, but it would not be straightforward to be able to match both function syntax and the Maybe a ~> b syntax (off the top of my head, every signature would need to have multiple parse trees which would all need to be searched).

By the way, I'm quite confused by the results that ~> currently returns!

Anything that we cannot parse we treat as a name, and ~> doesn't parse to anything, so it falls back to a name. Those signatures that it matches are also ones we cannot (currently) parse, so they also become names, and the fuzzy matcher likes those best. The fuzzy matcher returns a score, maybe if everything scores very poorly I should say "No matches"?

davidchambers · 2017-02-12T14:43:57Z

This discussion has made it apparent to me that fuzzy matching algorithms don't sit well with me. Web search engines such as Google are incredibly useful, of course, and are necessarily fuzzy. In more limited domains, though, I prefer algorithms which I understand (or could understand given enough time). I would like to be able to state definitively—without consulting a computer—the matches for a given search term.

I'm quite possibly anomalous.

I don't want my preferences to block this useful feature. Let's get the user interface in good shape then release the feature so that people can start using it and provide feedback. We can tweak the weightings as we see fit.

kedashoe · 2017-02-12T18:14:15Z

I don't have any attachment to the fuzzy search. I was planning to write a simpler one at some point anyway. For now, I'll play around with the scores it returns, I think returning some results no matter what is causing more harm than good.

kedashoe · 2017-02-13T19:34:37Z

I've updated the fuzzy searcher. No third party lib, just very simple search and score. Results look pretty good to me. I've also removed type info from sigs that can't be parsed, this seemed to be causing some confusion.

Also rebased. The bold that was added looks really nice in the search results :)

When you are ready to merge, please post to let me know before merging. I will release 1.0.0 of both the parser and searcher at that point, update the deps, make sure everything is still working, and then let you know it is ready to merge.

davidchambers · 2017-02-13T22:03:05Z

package.json

    "marked": "0.3.5",
-    "sanctuary-style": "0.4.x"
+    "sanctuary-style": "0.4.x",
+    "uglify-js": "^2.7.5"


Is there a reason to use ^2.7.5 rather than 2.7.x in this case?

davidchambers · 2017-02-13T22:04:51Z

src/search.js

+  return function(el) {
+    container.appendChild(el);
+  };
+}


Since we have Sanctuary available to us, should we use S.curry2 here?

davidchambers · 2017-02-13T22:06:25Z

src/search.js

+  var codes = document.getElementById('toc').querySelectorAll('li a code');
+  var as = map(getParent, codes);
+  var newEls = map(initSigResult, as);
+  return newEls;


I don't think the names add clarity here. Let's nest expressions:

return map(initSigResult, map(getParent, codes));

Do we have compose so we don't map over it twice:

map(compose(initSigResult, getParent), codes)

davidchambers · 2017-02-13T22:07:51Z

src/search.js

+
+// Node -> String
+function extractSignatureText(el) {
+  return el.innerText.trim().replace(/\s+/g, ' ');


S.unwords(S.words(el.innerText)) would be nice here. :)

davidchambers · 2017-02-13T22:11:52Z

src/search.js

+  }
+  else {
+    hide(state.containerNo);
+  }


I don't much like the show and hide functions as they're impure. I'd prefer this mutation to appear in situ:

state.containerNo.style.display = matches.length === 0 && q.length > 0 ? 'block' : 'none';

davidchambers · 2017-02-13T22:12:46Z

src/search.js

+  clearChildren(state.container);
+  // if there is no query, do not show any matches
+  if (q.length > 0) {
+    for (var i = 0; i < matches.length; ++i) {


Let's use matches.forEach here to avoid the index variable.

davidchambers · 2017-02-13T22:13:29Z

src/search.js

+  searchInput.focus();
+  searchInput.addEventListener('keyup', handleSearchKeyUp);
+});
+


davidchambers · 2017-02-13T22:15:04Z

style.css

@@ -111,6 +111,10 @@ a code {
  top: -0.05em;
 }

+#search-results > div {


Matching elements by tag name is inadvisable. Let's add an id or class name to the div and use a more precise selector here.

davidchambers · 2017-02-13T22:17:26Z

src/search.js

+  return Array.prototype.map.call(x, f);
+}
+
+// Node -> Node


I'd like to be able to run ack '^ *//' src/search.js to view all the type signatures. Please update this signature (and others) to include the function name:

// getGrandparent :: Node -> Node

kedashoe · 2017-02-14T01:01:09Z

updated.

My eslint knowledge is next to zero. I've fixed all the ones that looked like they should be fixed and am left with:

error 'require' is not defined
error Use the function form of 'use strict'
error Expected a function declaration

On that last one, since I am using S now and currying a few functions, I changed all function declarations to be var foo = function foo... to be consistent.

davidchambers · 2017-03-07T15:56:36Z

Are you happy for me to push to your branch, Kevin? I'd like to have a go at adding a dedicated /search/ page.

kedashoe · 2017-03-07T16:50:06Z

Sure, do I need to do anything?

davidchambers · 2017-03-07T16:52:34Z

Sure, do I need to do anything?

Nope. I'm going to rebase to resolve merge conflicts before I make any changes. Once I've done so you'll need to check out a fresh copy of this branch to avoid merge conflicts locally.

davidchambers · 2017-04-15T09:56:25Z

We must resolve kedashoe/hindley-milner-search#4 before merging this pull request.

davidchambers · 2017-04-17T13:10:41Z

Do we have any control over the fuzziness? It's great that a search for map finds map, bimap, and promap, but I don't think it should find Maybe#inspect.

kedashoe · 2017-04-18T05:57:02Z

Do we have any control over the fuzziness? It's great that a search for map finds map, bimap, and promap, but I don't think it should find Maybe#inspect.

see kedashoe/hindley-milner-search#6. will merge and release if that looks good to you.

kedashoe · 2017-04-18T22:03:54Z

will merge and release if that looks good to you.

0.2.0 up

davidchambers · 2017-04-19T10:28:35Z

I've updated this branch to [email protected]. We're now specifying {fuzzy: false} which fixed the overeager matching of names, but now a search for a -> a returns no results.

@kedashoe, can we perform substring matching of function names without losing the ability to search by type?

kedashoe · 2017-04-21T04:57:25Z

Sorry about that, I've released v0.2.1 with the fix.

davidchambers · 2017-04-21T18:30:53Z

Thanks for the update, Kevin. :)

I still can't find S.I: neither I nor a -> a finds it. Have you any idea why this is the case?

kedashoe · 2017-04-21T21:54:23Z

src/search.js

+    var search = HMS.init(Array.prototype.map.call($els, function(el) {
+      return el.innerText.trim().split(/\s+/).join(' ');
+    }), {fuzzy: false}).search;
+    var $prevSearch = '';


What does $ prefix mean? Why does $prevSearch have one but not q below?

In 6e24452 I replaced the state object with various variables. I assumed each of these variables to be stateful, and used the $ prefix to remind myself of this.

kedashoe · 2017-04-21T21:59:03Z

src/search.js

+          $container.removeChild($container.childNodes[0]);
+        }
+        // if there is no query, do not show any matches
+        if (q !== '') {


I originally had the empty string return all matches simply because I was culling results from the current DOM rather than building a new list. I'm not sure which would be more common, but I can add an option to return all or none on empty input and we wouldn't need this conditional in userland either way.

Since we'll be displaying results at /search/ rather than at /, displaying all results for an empty query seems right to me. I've removed this check. :)

I had to move this logic a little in the latest release. Not a million percent sure we're on the same page but just let me know if empty string is not doing what you want now.

kedashoe · 2017-04-24T05:02:55Z

New release up, a -> a and I should both find I now.

One other note, when I was playing around with my local copy of sanctuary-site, I was not getting many results for anything at first. This was due to \u2060 in our arrows (I feel like I remember discussion about this but couldn't find the PR), removing those fixed things.

davidchambers · 2017-04-24T11:16:06Z

Makefile

@@ -22,6 +23,12 @@ vendor/ramda.js: node_modules/ramda/dist/ramda.js
 vendor/%.js: node_modules/%/index.js
 	cp '$<' '$@'

+js/hm-search.js: node_modules/hindley-milner-search/hm-search.js Makefile
+	$(BROWSERIFY) --standalone HMS -- '$<' >'$@'


It would be nice if a browser build were available. This is related to kedashoe/hindley-milner-parser-js#1.

browser standalone files included in v0.2.3. You should see hms.js and hms.min.js now. Exported as HMS as you did.

Excellent! I've updated the makefile to simply copy hms.js, so we no longer depend on Browserify. :)

chughes87 · 2019-11-24T00:23:05Z

Bump on this PR! I'd love to see this merged soon...

kedashoe mentioned this pull request Jan 30, 2017

function search #11

Closed

kedashoe force-pushed the search-v2 branch from 3a59906 to dcee0ed Compare February 10, 2017 23:03

kedashoe force-pushed the search-v2 branch from dcee0ed to abf622f Compare February 13, 2017 19:29

davidchambers reviewed Feb 13, 2017

View reviewed changes

src/search.js Outdated

searchInput.focus();

searchInput.addEventListener('keyup', handleSearchKeyUp);

});

Copy link

Member

davidchambers Feb 13, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👾

davidchambers reviewed Feb 13, 2017

View reviewed changes

kedashoe force-pushed the search-v2 branch from abf622f to 97e0f20 Compare February 14, 2017 00:58

davidchambers force-pushed the search-v2 branch from 97e0f20 to b4ec80e Compare March 7, 2017 16:54

search

6acbe96

davidchambers mentioned this pull request Apr 14, 2017

browser support kedashoe/hindley-milner-parser-js#1

Open

davidchambers force-pushed the search-v2 branch from b4ec80e to 6acbe96 Compare April 14, 2017 07:32

davidchambers added 2 commits April 16, 2017 01:40

refactoring

6e24452

[email protected]

11b47db

kedashoe mentioned this pull request Apr 17, 2017

make fuzzy search optional kedashoe/hindley-milner-search#5

Closed

[email protected]

71d3b85

[email protected]

b133339

kedashoe commented Apr 21, 2017

View reviewed changes

davidchambers added 3 commits April 22, 2017 10:13

show everything when searching for ""

b556b1c

remove $prevSearch optimization

03345c4

add search/index.html

de62ed2

davidchambers added 3 commits April 24, 2017 11:56

[email protected]

37df703

move search functionality to /search/

4a95614

remove unused file

340bd9e

davidchambers reviewed Apr 24, 2017

View reviewed changes

[email protected]

551a2c5

Avaq mentioned this pull request Nov 14, 2022

Searchbar on website https://sanctuary.js.org/ sanctuary-js/sanctuary#722

Open

search #23

Are you sure you want to change the base?

search #23

Conversation

kedashoe commented Jan 30, 2017 • edited by davidchambers Loading

davidchambers commented Jan 30, 2017

kedashoe commented Jan 30, 2017

davidchambers commented Jan 30, 2017

kedashoe commented Feb 10, 2017

davidchambers commented Feb 11, 2017

kedashoe commented Feb 11, 2017

davidchambers commented Feb 11, 2017

kedashoe commented Feb 11, 2017

davidchambers commented Feb 12, 2017

kedashoe commented Feb 12, 2017

kedashoe commented Feb 13, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

kedashoe commented Feb 14, 2017

davidchambers commented Mar 7, 2017

kedashoe commented Mar 7, 2017

davidchambers commented Mar 7, 2017

davidchambers commented Apr 15, 2017

davidchambers commented Apr 17, 2017

kedashoe commented Apr 18, 2017

kedashoe commented Apr 18, 2017

davidchambers commented Apr 19, 2017

kedashoe commented Apr 21, 2017

davidchambers commented Apr 21, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

kedashoe commented Apr 24, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

chughes87 commented Nov 24, 2019

kedashoe commented Jan 30, 2017 •

edited by davidchambers

Loading