Brian Teague (Jan 04 2025 at 02:19): Brian Teague (Jan 04 2025 at 02:19):I am extremely excited about all three of these proposals, and was curious about a roadmap tracking the progress of these?
I know there is mention of freezing the current iteration of Roc, and was wondering the approach about implementing these proposals via a dedicated feature branch? Have they been pretty much finalized?
What is ROC's approach to version control long term regarding introducing breaking changes in the future? I think for better adoption, conversion scripts might be needed if people are using ROC in production (which I think is going to happen a lot once these proposals are implemented)
Anthony Bullard (Jan 04 2025 at 02:46):We are doing our best to provide migration scripts for the things that we can - I've done that for both the move to snake_case identifiers and the new parens-and-comma calling syntax
Anthony Bullard (Jan 04 2025 at 02:46):Purity inference is a little harder to have a fix-script or migration for, but the changes are relatively minor
Anthony Bullard (Jan 04 2025 at 02:47):I think we _might_ be able to have a migration for Opaque Refs => Custom Types. The syntax is not changing in a HUGE way.
Anthony Bullard (Jan 04 2025 at 02:47):And I'm about to begin work on the new lambda syntax and we will support both for a time and add a migration for that as well
Sam Mohr (Jan 04 2025 at 02:54):Purity inference has already been implemented in the language by @Agus Zubiaga , it works really well (better than Tasks). We already have pre-releases for basic-cli, basic-webserver, and basic-ssg, we just need to fix an issue with Hyper and then they're good to merge. roc-ray is already released with Purity Inference.
So yeah, you can already use it with these platforms, we just need a little bit longer and then we'll be making an announcement for it then. Maybe a few days? No promises. We'll have an upgrade guide
Sam Mohr (Jan 04 2025 at 02:58):Shoutouts to Luke Boswell on doing most of the work upgrading platforms. A champion, that one
Anthony Bullard (Jan 04 2025 at 02:59):Luke is a boss. Literally, he's someone's boss
Brendan Hansknecht (Jan 04 2025 at 03:09):What is ROC's approach to version control long term regarding introducing breaking changes in the future?
Currently we are pre versioned releases. As such, the release strategy is pretty minor. Generally speaking, when breaking changes are incoming, we:
testing instead of latest release. So downloading the latest will get the version before any breaking changes.latest release.If possible, we leave features around that enable old code to keep running. For example, Task still works for now despite purity inference being ready to go.
Brendan Hansknecht (Jan 04 2025 at 03:11):was wondering the approach about implementing these proposals via a dedicated feature branch?
They get implemented directly to main via PRs. Occasionally, they get delayed a little before submitting to batch breaking changes and deal with the release cycle above.
Brendan Hansknecht (Jan 04 2025 at 03:11):Have they been pretty much finalized?
Not at all. Purity inference is done, but no work has even started on static dispatch or custom types.
Sam Mohr (Jan 04 2025 at 03:12):I have started work on static dispatch and custom types as part of my effort to rewrite canonicalization. In short, the canonicalization is some of the oldest code in the Roc repo, and we want to improve its performance and cache-friendliness by first canonicalizing modules in silos without any knowledge of any other Roc code. This makes the new roc_can_solo produce deterministic output that is later recombined in roc_can_combine (name is WIP) kind of like linking objects into a binary.
There are lots of changes we want to do in addition to that.
To that end, I've been pushing to "run in a straight line" here: if we were to try to make all of these changes incrementally on top of the canonicalization rewrite, it'd take a whole lot longer. So we're doing it all in one go to get it to users faster. That will involve a big code switch at some point which means that writing Roc will look a lot different all at once. The hope is that around that time, Roc will be close to the shape we want it to be in the medium-term, so it's not so bad to make the breaks. After that, we'll try a lot harder to maintain stability to attract people to using Roc
Brendan Hansknecht (Jan 04 2025 at 03:12):I think for better adoption, conversion scripts might be needed if people are using ROC in production (which I think is going to happen a lot once these proposals are implemented)
Hopefully sometime late 2025 we will have our first numbered release v0.1.0
Sam Mohr (Jan 04 2025 at 03:20):I don't yet have a branch published because of the scale of the change. My approach here is to get a rough draft of what the changes will look like by machete'ing what code makes sense until I can finish writing down a plain-English guide of what the code will do. I'll then be trying to break it up into as reasonable-to-code-review chunks as I can. I'll try to make the branch public as soon as I think it at all resembles what we want to do in the future
Sam Mohr (Jan 04 2025 at 03:22):I'm planning on walking this road alone, but if anyone really wants to work on implementing this change, I'd be happy to share my playbook and we can try to split up this work
Sam Mohr (Jan 04 2025 at 03:22):If anyone wants to know any particular details in the meantime, feel free to ask!
Last updated: Jul 06 2025 at 12:14 UTC