I don't think I need to explain why that's useful to you guys, lol. It's the main selling point of Relude in my opinion. Interface type unification - Using module functors to unify the BsAbstract module types with standard library API's is wicked cool. On the topic of broad functor usage across the library, I guess I would break it into two use cases: I really like the broad use of module functors in this library. I wish I had deeper knowledge of the OCaml type system, but I only know one or two possible solutions. One other concern with this approach is that this library already has a quite steep learning curve with all the abstractions, so maybe it's the case that we need to favor convenience over runtime optimizations (in some cases), and leave the raw performance to more specialized libraries? I'm not sure I actually feel that way, but just a thought. I'm not sure I'll undertake this task myself anytime soon, and I'm not sure we want to do it or not, but I think we're open to discussion (and let's discuss before anyone submits a PR). I'm personally still kind of neutral on whether to go down this road, and how/whether it might affect other places where we have module functors. Yeah, we are aware of the closure issues in the library, and the runtime implications - it's unfortunate b/c we do use module functors pretty heavily, and we're trying to find a balance between convenience and other concerns like bundle size, DCE, runtime allocations, etc. I assume you're referencing the techniques described here: - is that right? I'm not sure if that's the best solution, but it's an - thanks for the issue. But if we did that, then maybe we could define all/most of the API outside of the functor ahead of time, and assign them by reference to equivalently named functions inside the constructed module. I'm not sure how to solve this issue without moving the id type constraint into the type parameters of type. I know performance isn't the primary concern of this library, but you can imagine users being surprised if they use the Map module in any serious way, especially since this issue is not common elsewhere in the library.

The resulting API is (IMO) slightly more ergonomic than that of Belt.Map, but not so much more that it justifies 40 new function allocations per map instantiation. The WithOrd functor takes care of providing the Comparable module type required by Belt, while simultaneously requiring a similar module type which satisfies the signature. This occurs within nested scopes as well as the top-level scope. That is to say, each call to will produce a new version of each function in the entire Map API (over 40 of them currently). The compiled output of the module functor, while convenient, creates a large closure for each application of the functor.

Cannot map sheepshaver data no error