Brainstorm future breaking changes

[mlms13]

Once we've made a 1.0 release, it will be time to start thinking about the next round of larger, breaking changes that we'll plan on making. Some of those will probably require discussion before we even agree that the changes are a good idea (or worth doing).

Let's have that discussion here, and once we've agreed that a change is worthwhile, and once we've come up with a rough plan for that change, we can split it out into its own ticket.

Some ideas so far:

• Monorepo/package set options #326
• IO refactor/reimplementation #328
• Start using named arguments for functions with ambiguous behavior #325
• Interface files + move docs into those interface files
• Drop ReScript support so we can take advantage of newer OCaml features (like binding ops 🎉 🥳 ✨)

There's probably way more than this. Feel free to add ideas and debate the merits in the comments. 😁

[johnhaley81]

I have a few things that would be nice. (Those might be better as single issues?)

• The Sequence stuff is very costly in terms of perf. Finding a way to not have it just tank as a list of things get into 4-digits
• IO is not stack safe and I have seen an instance where it blew up in a very complicated calculation
• Something that works with dates and times in a more functional pattern
• Interface files?

I'm sure there are more but that's top of mind

[andywhite37]

The Sequence stuff is very costly in terms of perf. Finding a way to not have it just tank as a list of things get into 4-digits

Do you recall any specifics on which things related to Sequence were causing problems? I think SEQUENCE in relude was just an attempt at creating a module type interface to abstract "array-like" things, so we could have implementations of things like NonEmpty that were backed by a List or an Array. If there are performance concerns related to something with Sequence it might be because something is using a List as the implementation for something that doesn't work well with a List, like random access. I would not be surprised if there is some non-optimal code in places using Sequence though!

IO

We've discussed this a bit, but for IO, I think the most effective solution might be to keep IO as it is now, and deprecate it, and implement a new IO-like effect type, that has some of the perf optimizations and features that we know that we want. @mlms13 and my colleague at SimSpace implemented this xio library in typescript, which is based on Scala ZIO, so we could probably look to re-implement that in Reason: https://gitlab.com/simspace-oss/xio - the license looks to be MIT-like, so seems pretty flexible. I'm afraid that trying to change IO into something more like this would cause more heartache than just implementing a new effect type and then giving people the ability to migrate to the new type over time. I also think that an effect type like this probably deserves to be in its own package/repo, because it's complicated enough where we might want the ability to maintain it outside the core library.

Dates & Times

Yeah, this would be awesome! I've kind of liked Luxon, so maybe we could look to that for inspiration on the API, and build out relude-eon more. We should talk more about the things we want with this.

Interface files

We had a discussion offline, so just adding my thoughts here. I'm open to having interface files, but I want to make sure we have a good workflow for generating them, and then maintaining them going forward, since there will be a lot of functions to be exposed and document via the interfaces. I think we can do it.

[trite]

+1 for making a new IO-like effect type and leaving the old one alone for compatibility. Perhaps name it RIO. Has the fun benefit of being able to say you're "moving to RIO" when updating code to use it.

[johnhaley81]

Do you recall any specifics on which things related to Sequence were causing problems? I think SEQUENCE in relude was just an attempt at creating a module type interface to abstract "array-like" things, so we could have implementations of things like NonEmpty that were backed by a List or an Array. If there are performance concerns related to something with Sequence it might be because something is using a List as the implementation for something that doesn't work well with a List, like random access. I would not be surprised if there is some non-optimal code in places using Sequence though!

I'm pretty sure it was doing List.sequence over a something with like, 5k items and it took way more time than is reasonable.

We've discussed this a bit, but for IO, I think the most effective solution might be to keep IO as it is now, and deprecate it, and implement a new IO-like effect type, that has some of the perf optimizations and features that we know that we want.

That's probably the best idea. IO is the biggest and roughest thing in the library so splitting it out does make a lot of sense IMO. We did add in some built-in logging and stuff to it but it would be nice as well to have it also contain things like the environment state that it's in instead of keeping that implicit.

Yeah, this would be awesome! I've kind of liked Luxon, so maybe we could look to that for inspiration on the API, and build out relude-eon more. We should talk more about the things we want with this.

We us https://github.com/davidgomes/bs-luxon a lot at Qwick but the bindings are pretty rough to use. Luxon itself is nice though. We also started using date-fns which are good.

[andywhite37]

Ah, sequence like the Applicative thing - sorry, I thought you meant the Sequence module type. Yeah, I don't think we tried to benchmark any of that stuff, so there are likely problems. I think fp-ts might have special more optimized implementations of things like sequence for things like Arrays, so that might be worth exploring.

[andywhite37]

+1 for making a new IO-like effect type and leaving the old one alone for compatibility. Perhaps name it RIO. Has the fun benefit of being able to say you're "moving to RIO" when updating code to use it.

I was thinking about that too - I wanted to reach for RIO, but that might be confused with ReaderIO, which is a thing in other ecosystems. RIO would probably in fact be a ReaderIO, but it might not use the Reader abstraction from relude, so it could add some confusion. I thought it could be fun to name it QIO (pronounced "key-oh"?), as just an arbitrary play on ZIO or XIO (but also with the Qwick tie-in). Also, if we build a new effect type like RIO/QIO/whatever, it could be open-sourced under the qwick org, which could be a good recruiting tool.

[andywhite37]

I started a new issue to discuss monorepo-related topics: #326

I see that monorepos would solve some of the problems we have with versioning and compatibility, but I also see some potential downsides of moving to a monorepo. An alternative might be to re-open the investigation of a package-set system for Reason - I think that could be a really cool addition to the community if we could get something set up. I just wanted to discuss that more.