Problem-solving: Language versioning.

[vrurg]

We currently use letters for defining language revisions. Combined with 6. a letter forms a language version like 6.c.

The language renaming PR proposes changes to this scheme.

[vrurg]

The proposal says to just drop 6. and use uppercase letters for revisions: Raku E, for example. It coincides with my attempt to produce a solution to multi-versioned core classes in rakudo/rakudo#3112. Though I don't see why getting rid of 6. at all and what would make Raku 6.E look worse that the former example?

Yet, there is a proposal from @AlexDaniel to use semvers.

While generally agree that changing -errata branches is not right as it makes following older standards a moving target, the proposal complicates the solution for multi-core issue. Let's say we have language versions Raku 1 and Raku 2. Both are defining a CoreClass. Following the namespace solution for referring to individual class version would look like CORE::1::CoreClass which is not right.

In #80 I also proposed :from<lang-ver> adverb for this purpose. CoreClass:from<2> surely looks ok, but it requires more changes with a potential to clash with other syntax constructs.

[AlexDaniel]

The proposal says to just drop 6.

Well, it used to propose that. I changed that in https://github.com/perl6/problem-solving/commit/e4461ed9f23e0cfc2f107cf078cb090541852b39. As of right now it wasn't changed back :)

[vrurg]

Ah, right. Anyway, the word was said. The idea of using uppercase letters appeals to me because I was considering CORE::e:: namespace but it's no better than CORE::1::.

[Grinnz]

One thing I would really keep in mind when thinking about this is that versions are forever. There will always be historically a rakudo implementation for the language version 6.c. So it may be impolite to future packagers, etc to have a newer version that might compare older. And also consider what will happen with old code that contains "use v6.c" or whatever.

[Grinnz]

From semver "Numeric identifiers always have lower precedence than non-numeric identifiers." so I think moving the major version to a letter may work, with those constraints - I just want to make sure it's considered.

[AlexDaniel]

@Grinnz yes, of course. Thank you for your concern. It's just that these discussions are happening all over the place so right now it's a bit hard to bring sense into them :)

[vrurg]

Briefly, if renaming happens, I would sum up my point of view:

1. 6. prefix remains as a heritage. Though letters become upper case: 6.E, v6.E.
2. Older standards get their patch numbers: v6.C.1
3. For naming purposes 6.X is interchangeable with just X where context allows: Raku E, Raku C.1 are equivalent for Raku v6.E, Raku v6.C.1.
4. use v6 statement won't be needed anymore. But use v6.E.PREVIEW; is still the way to define code version. Alternatively, use :rev<E.PREVIEW>; can be used. The actual syntax is irrelevant.

Wether renaming will take place or not, as a side note, I would also add .C (or .c) suffix to corresponding core. I see no point of making c a special case as it is now. So, we'd get core.C directory and CORE.C.setting. This would allow a lot of code to get simpler and consequently a little faster.

[FCO]

Why using 6?

_{Sent with GitHawk}

[vrurg]

See item 1 from my list. It's a heritage to keep our roots.Raku is also a bit of word play around similar pronunciation of _roku_ which stand for _six_ in English, and _raku_ for _easy_ or _comfort_.

Also, as @Grinnz mentioned, 6.c and 6.d are there to stay. Abrupt change of versioning would be confusing to packagers and automation scripts.

Support for both versioning schemes (the old one and any new one) will require more code to handle it. I don't think it worth it.

Switching to an absolutely new versioning scheme won't bring us nothing but perhaps aesthetic satisfaction, except for simplifying the situation with -errata branches. But the latter could be taken care of by adding a patch number to the language version. This might not be looking as pretty as we'd like it to be, but technically and logically it's ok.

[hythm7]

Raku v6.E, Raku v6.C.1 looks too much noise to me.

[vrurg]

For the communication purposes one can use Raku E alongside with Raku 6.E and Raku v6.E, I see no problem with that.

What is related to v6.C.1 – it is mainly for marking -errata branch fixes. Those are rare and would have pretty much specific use. Usually they won't surface for everyday use. Although a script could require a fixed language revision with use v6.C.1;. But that is no different to me from use v1.1.1 or alike.

[FCO]

If the 6 continue existing, I think lower cased letter makes more sense... but we don’t really need the 6. I prefer Raku E

_{Sent with GitHawk}

[nxadm]

What about something similar to Rakudo releases:

Raku v2019.07

If digits are compared 2019 > 6, so no trouble there.

[vrurg]

@FCO

If the 6 continue existing, I think lower cased letter makes more sense... but we don’t really need the 6. I prefer Raku E

I'm considering case-insensitive letters. Besides, you're still mixing up representation with technical use. Raku E is welcome to be used. Perhaps and likely it would be the official release name. But internally, for the scripting and coding purposes, v6.e or v6.E would be used.

Terminologywise, e or E is revision; 6.e is version. Just different representation of the same thing.

@nxadm

What about something similar to Rakudo releases:

Raku v2019.07

If digits are compared 2019 > 6, so no trouble there.

But language is not being released neither monthly nor yearly. Only when ready. How would one remember what was a previous release of, say, v2020.12?

Besides, think of cores. We currently have core, core.d, core.e. Now, will it be core.2020.12?

Another thing. Each core has own stash. They're currently not represented by namespaces, but in 6.e one can scan through them with UNIT::OUTER::. rakudo/rakudo#3112 introduces CORE::E::, CORE::D:: which is pretty neat, I think, and fits into overall logic. How would v2019.17 fit into this?

Overall, we have the following areas where language versioning affects things:

1. Public representation. Raku E is great for this.
2. Roast
   
   
   
   • actual version (VERSION file)
   
   
   • -errata branches (need for patch versions)
   
   
3. Use in code. Mainly for specifying module/script code version. Existing or possible variants are:
   
   
   
   • traditional use v6.e;
   
   
   • use Raku:rev<e> or use Raku:ver<6.e>
   
   
   • shortcuts for the above: use :rev<e>, use :ver<6.e>; basically use v6.e is a shortcut too.
   
   
4. CORE definitions and build subsystem.
5. A thing which not clear yet, but the issue is already arising. It wasn't possible to redefine a class in CORE before my recent fixes. Now, we already have actually two PseudoHash'es. One is used for pre-6.e code, another is for 6.e. They do behave differently, hence different implementations to prevent spaghetti code. But there is actually no way yet to refer to a specific class yet. I propose CORE::D::PseudoStash as a solution. In TIMTOWTDI paradigm another way would be PseudoStash:from<e> or alike (the actual adverb can be any).
6. Version support by the grammar, actions, and World to actually load correct COREs for code. The code is already somewhat messy. I would like to simplify it by naming 6.c core as core.c. But still, there're few locations where versions are parsed and treated. Extra code equals to extra bugs and CPU ticks.
7. We also have a lot of old code floating around like 3rd party modules and apps we have to support.

Not sure if I'm not missing something.

The decision must take into account all the above items.

[nxadm]

What about something similar to Rakudo releases:
Raku v2019.07
If digits are compared 2019 > 6, so no trouble there.

But language is not being released neither monthly nor yearly. Only when ready. How would one remember what was a previous release of, say, v2020.12?

C89, C++17 and so on?

[vendethiel]

C, C++, Cobol, Fortran, ECMAScript all have year numbers as versions.

[vrurg]

The thing nobody of you mentions is that none of those languages supports multi-version code. There is no need for language-version pragmas in the source which are better be short and tell something to the code author. I would be the first one to throw a stone into the one who made me typing use v2019.12!