Sky Rose (May 21 2024 at 22:08): Sky Rose (May 21 2024 at 22:08):An idea for once Roc has numbered versions: What if there was a line in the module header that described which language version a file/app/library was written in?
This idea is inspired by this thread about builtin version bumps, and this thread about rocup, though it bounced between language versions and package versions so I wanted to make a thread specifically about language versions.
The motivation would be to avoid the versioning hell that you run into all the time with Python where each version is 100 different languages that look alike, and you have to track down the exact version of Python that an application was written against, or you'll run into cryptic errors.
Roc's platforms already solve a similar problem that I run into in JavaScript, where you have to target a specific version of JS with certain browser APIs, or target Node which has completely different APIs. That's solved because those changes would be part of the platform and would cause an app to not compile if you used the wrong platform version. Here I'm talking more about language changes (builtin API changes, or language features), not the platform.
It would be optional, for easier scripting and for backward compatibility.
If the version is there and the compiler doesn't recognize the version, it could maybe upgrade/downgrade to an appropriate compiler version, or give a descriptive warning (maybe while trying to compile anyway).
There would be lots of details to figure out about the difference between compiler versions, language versions, and how to determine compatibility, and how to avoid having to update source files for non-breaking compiler changes.
I can't think of any other languages that put their language version in their source files. Lately I've been using mise to put language versions in a .tool-versions file.
Richard Feldman (May 21 2024 at 22:16):we could do something like app 1.3 [main]
Richard Feldman (May 21 2024 at 22:16):I wouldn't mind making something like that mandatory
Richard Feldman (May 21 2024 at 22:17):it's pretty unobtrusive and it would let you get much nicer error messages if you try to build something using a version of the compiler that's incompatible with it
Richard Feldman (May 21 2024 at 22:19):or like app 2024 [main] if we end up doing an editions thing
Sky Rose (Dec 23 2024 at 01:12):Now that Roc has numbered versions, this idea could be worth thinking about again.
There's also an argument for trying to add it to the #ideas > v0.1.0 list: The main theme for v0.1.0 is stability, and this would make any future breaking changes less painful.
Sky Rose (Dec 23 2024 at 01:15):Oh, I hadn't seen that this was just mentioned in #ideas > compiler version management , with a much more detailed proposal there!
Anthony Bullard (Dec 23 2024 at 02:02):I actually really like this, not only for apps, but also packages and platforms. If we are changing headers, can we add a name for package and platforms as well? It would be helpful for docs generation and I'm sure some other tooling
Richard Feldman (Dec 23 2024 at 02:04):I think the name idea overlaps with #ideas > package naming and search - definitely a rabbit hole there! :big_smile:
Anthony Bullard (Dec 23 2024 at 02:08):I think it's a very important thing to nail down. Especially to determine if we are going with the "main.roc is the entry point AND configuration point for this unit of compilation" idea for the long haul
Richard Feldman (Dec 23 2024 at 02:33):yeah if you have any thoughts on that thread, feel free to add to it - I'd love to hear them!
Last updated: Jun 16 2026 at 16:19 UTC