A language level specification should be exact

[lizmat]

The specification of a language level (aka use v6.d or TWO) has traditionally meant a minimum set of semantics and capabilities. I think it could be argued that this is wrong.

The current situation is that use v6.d with a recent Rakudo compiler release gives you many more features than the initial release in November 2018. And if you specify use v6.e.PREVIEW you get an additional set of new semantics and features.

I think it can be argued that the next language release (THREE, or v6.e as it is tentatively called now) should be the first language release that guarantees an exact set of semantics and capabilities.

And that any additional developments must happen in FOUR ONLY (or in v6.f.PREVIEW as we would call it now).

[2colours]

Agreed. It's mainly the same argument as with the absence of a use version statement: somebody who wrote code in accordance with v6.d or whatever version, can have no guarantees that it will actually work because random name collisions and "wrong assumptions" (i.e assumptions that hold in the minimal implementation but might break if the release contain other things) can get in the way.

I think the easier part is to agree about this convention but I feel uneasy if this cannot be actually enforced for the implementation to keep. Which brings us back to https://github.com/Raku/problem-solving/issues/381 and the unsuitability of Roast to define the language.

[codesections]

I like this proposal but only if we can seriously commit to a much more rapid release cadence for language versions. If we release a new language version, say, every six months, then guaranteeing an exact set of semantics would be great.

If, on the other hand, we release new language versions every 3 years (the gap between v6c and v6d or 5+ years (the current gap), then I think this proposal would be a very bad idea indeed. That's because most Raku users won't want to miss out on multiple years worth of features/improvements and, as a result, a tremendous amount of Raku code will specify that it runs on the PREVIEW version. But once that happens, PREVIEW loses it's status as a place for work-in-progress features that aren't guaranteed to work at the moment; it'd become the de facto released version of Raku. And that'd be a real loss.

[2colours]

@codesections all the more reason I'd like to get feedback on #381 (which is really just a reiteration of ages-old issues). Breaking somebody's 6.d code in a more recent runtime supposedly supporting 6.d is something that should never happen - let me emphasize this: one single occasion where user code breaks within the same language version by design rather than a mistake, is already unacceptable.

Now, if we just accepted that actual code does depend on the runtime and worked out a strategy for that, this issue would mostly disappear. The releases would be themed around versioning, probably it wouldn't be continuous but people could get new features, say, every half a year. It would have mostly the same implications as "reasonably rapid releases", except it would also cover foggy areas like metamodel stuff and whatever Roast (unfortunately) doesn't cover.

[Leont]

I like this proposal but only if we can seriously commit to a much more rapid release cadence for language versions. If we release a new language version, say, every six months, then guaranteeing an exact set of semantics would be great.

Exactly this. This will only work if we abandon our culture of waiting for $holiday in unknown year