Native compilation
mlms13 opened this issue · 7 comments
We've been talking about what it would mean for Relude to compile on native, and while we have quite a bit of work to do on our own, I think some changes may also be required in bs-abstract for that to happen. Specifically, a couple things come to mind:
- Implementations for some types (maybe
stringandarray?) currently depend on Bucklscript/JS-specific functions bs-abstractincludes implementations for types likeJs.Date.tandJs.Promise.tthat are JS-specific- There might be other considerations related to package management and build system configuration... I don't really know the details here.
One idea might be to split all of the typeclass definitions in Interface.re into a separate repo that doesn't provide any implementations. This could allow you to have implementations in separate repos based on the OCaml stdlib and Bucklescript's Belt.
We don't have an immediate need for this, but it's something we've had on the back burner for awhile, and I wanted to see what your thoughts are from the bs-abstract side. If we come up with a clear plan, I'm happy to do most of the actual work. 🙂
Yeah that's what I was thinking as well, I added some tickets a while back but I haven't gotten around to working on them:
https://github.com/Risto-Stevcev/bs-abstract/projects/1#card-21792242
https://github.com/Risto-Stevcev/bs-abstract/projects/1#card-21792242
I'm a little concerned though about all of these disconnected libraries, having one for interfaces, another for bucklescript implementations, another for native implementations, etc. Relude needs to be able to talk to these libraries and it'll become a headache to maintain.
Tablecloth has a different kind of setup, somehow they managed to bundle it all together into one repo. Maybe something like that?
The direction I've was ultimately thinking of taking for this project was like this:
-
Have a seperate repo with all of the interfaces, code shared between native, jsoo and bucklescript (using a similar technique to
tablecloth) -
One repo per data structure. So you would have a repo
bs-abstract-lists,bs-abstract-strings,bs-abstract-eff,bs-abstract-aff, etc, and it would have all of the implementations in there. And maybe eventually versions for native and jsoo, likenative-abstract-lists,jsoo-abstract-lists, etc.
The reasoning being is that smaller repos (do one thing and one thing well) don't run so much into the gatekeeper issues of open-source, maintainability, etc. It's tractable and has a better bus factor -- it's easy for people to pick up one of the smaller repos or fork it if there's disagreement. Purescript does this but goes a little too far because it has separate repos for the interfaces as well, and different repos for the same data structure, so it ends up way too fragmented. I feel like this is a good middle ground.
I'm also not opposed to merging into the reazon umbrella project in general, just that I wanted to keep this kind of unix-esque style in place, instead of large monolith like scalaz.
I'm not super familiar with the OCaml ecosystem as a whole, but does OCaml support something like #ifdef? I searched and saw some mentions of camlp4, ppx_optcomp, etc., but nothing that appeared to be built into the compiler. If something like that worked, that might help with the cross-platform implementation differences.
In terms of relude, I think it would be most helpful to separate out the interfaces into a separate library (which could maybe also include any implementations that are truly cross-platform). That way, we can just depend on the interfaces, and we (and anyone else) will have the freedom to manage the implementations, whether in the unix style, or the scalaz monolith style. I think if you decide to break up bs-abstract into smaller, more focused libs, I don't think it would affect us too much - we would just have to decide which of those modules to include vs providing our own implementations. We've had the same thoughts about unix vs scalaz style, and we're currently in the scalaz monolith boat, but I could see relude getting broken up into smaller pieces when the dust settles a little more.
I don't think it's necessary to merge your project under reazen, unless you really want to. I feel like the interface work you've done in bs-abstract is unlikely to change much, if at all, because it's so foundational, so it hasn't been a problem for us to depend on those interfaces (and many of your implementations) so far. Also, keeping your lib outside of our stuff makes it feel more like a "standard" rather than just "a standard that we created for ourselves", and it keeps us honest.
What made you want to fork off a separate project instead of work on this one anyway? I'm trying to figure out why nobody ended up just contributing to this project, yours is turning into the defacto project for this sort of thing because of contributions. It kind of bums me out tbh
That's really good to know! To be honest, we worked on an internal-to-our-work stdlib called Elude before I knew bs-abstract existed. I wanted to leverage the module system for typeclasses, but had a hard time wrapping my head around that until I found bs-abstract.
Once we understood how the interfaces in bs-abstract work, we started an effort to rewrite Elude to make better use of the module types you had defined here, which became Relude. At first, I didn't even realize that bs-abstract came with implementations, and it wasn't until quite a bit later that I stumbled across the Functions.re file in bs-abstract that defines some of the "functionality for free" utilities that you get from combining typeclasses.
By that point we had started adding types similar to RemoteData and NonEmptyList to Relude, which are useful in a broader fp ecosystem, but not normally part of a cateogry-theory-focused standard library. Plus we were focusing on adding very specialized utilities to make it easy to work with e.g. list(float), which ideally makes the library simpler for recent Reason converts from JS in a world without modular implicits, but feels (to me, at least) out-of-scope for bs-abstract.
Anyway, sorry for the wall of text. It just bums me out that you're bummed out. 🙂 Relude 100% would not exist without bs-abstract, and I really don't want to steal credit or contributions away from bs-abstract. I've been working on a couple new module types (MONAD_REC and LAZY), and I'm planning to upstream those here. Maybe we should also work closer on unifying what bs-abstract has in function/Functions.re and what Relude has in Relude_Extensions_*.re, because there's overlap there, and any extra stuff we have in Relude should maybe exist in bs-abstract, and Relude would no longer need to maintain that.
If there are other things we can be doing to direct contributions this way, let us know! Maybe a new unified org would make sense? Anyway, I just want to express how much we appreciate bs-abstract, and anyone who uses Relude is also using and benefiting from bs-abstract.
Yeah, I 100% agree with @mlms13 - we really appreciate the work you've done in bs-abstract, and we rely on it heavily. My previous comment was intended to be asking for you to do anything, or split up your library or do work on our behalf. I think you've just created a very useful set of typeclass module types, and we're just brainstorming on how best to modularize everything.
I think we forged our own path b/c we wanted the freedom to do things that likely wouldn't fit very well in your library, and the freedom to try things and make changes. When I was first learning bs-abstract, I got a strong sense that it was very focused on just the typeclasses and basic implementations, and things like string utilities and types like our AsyncResult, which is more of an application helper module, wouldn't belong. I actually really like that you kept your library focused on typeclasses and basic instances, and didn't add all the extra stuff, but maybe that's not what you were thinking.
Anyway, I'm also bummed that you're bummed - we have no lofty goals of making the most popular library or anything like that - we just wanted a library of things that worked the way we wanted them to, basically for our own sake, but we wanted to make it public so other like-minded people wouldn't have to reinvent the same wheels, just like we tried not to reinvent the wheels that you created.
I didn't mean to put you guys on the spot, sorry about that, just feeling pretty burnt out lately. I believe you guys about Elude, parallel thinking is very real and it's happened to me so many times too, and I don't think you guys were trying to steal credit because you guys mention it front and center that it's built upon this stuff. Thanks for that, I really appreciate it.