welcome all! :wave:

as something to talk about, these are some API-related Racket pull requests that have been on my mind lately: • https://github.com/racket/racket/pull/3054 • https://github.com/racket/racket/pull/3076 • https://github.com/racket/racket/pull/2592 • https://github.com/racket/racket/pull/2766

No one said there was going to be homework in this chat :smile:

I like 2592, I think 2766 ended up in the right place (ie rejected), I like 3054, and I like 3076

2766 is the set->hash one right?

From an outside perspective the API looked very weird. I don’t really understand what it was for.

on 2766 I was wondering if any contract profiling was done

It was for making iteration over sets faster

Sets are slow, compared to doing things over the hash representation

Is it the generic dispatch?

and tangentially, does that mean the proposed set->hash function could only work on the built-in hash-based set implementation, instead of an arbitrary set?

yes, see https://github.com/racket/racket/pull/2766/files#diff-df133fd5131b5b29c06772c4fbd86ea3R114-R119

:wave:

Hi all, and thanks @notjack for the channel. I actually have something.

Here’s a preview of an announcement post for a fuzzy search library. You don’t have to read it, but it does show more specifics. In summary, the matching algorithm I use is a port of someone else’s attempts to replicate Sublime Text’s search.

The search has exponential worst-case complexity. I wanted to check here if I could do better based on the ported implementation shown here: https://github.com/zyrolasting/fuzzy-search/blob/master/main.rkt

I’m not totally sold on the need for the exhaustive search, but then again, I’m not an expert on fuzzy matches.

you might be interested in https://docs.racket-lang.org/benchmark/index.html?q=benchmark

Also, since you’re thinking about fuzzy-search, you might look at/think about replacing the JS search in racket docs, which could be fuzzier

Huge improvement