problem-solving
problem-solving copied to clipboard
Raku
change the raku spec versioning
for someone who don't know the raku history, there is no way to understand that 6.e is actually the 3rd version of the spec.
so i really suggest raku3.
I've said it before and I'll say it again: the way we do versioning right now totally made sense when the language was called Perl 6. But with the proper name that we finally have now our current versioning is borderline stupid. We can't go back to 3, but I believe we can go to 7.0.0 or higher and drop the lettering. This was discussed fairly recently, but there wasn't a consensus or anything like that yet.
We can't go back to 3, but I believe we can go to 7.0.0 or higher and drop the lettering
I was about to write "we'd probably have to go to 7 to have the sorting work out correctly", and you beat me to it. I'm open to this, though would be interested to see further input.
if
eis higher than6, I'd prefer versione
We can prefer it in our bubble but everyone else is still confused about the letter. We didn't release 6.0 so a lot of people didn't realize that 6.c or 6.d means that we already had a proper language release. Raku 7.0.0 (or 7.0?) can be a great marketing potential.
I agree that the 6.x versioning scheme is quite awkward and we should get away from that.
My preference is to actually go back to version 1.0 instead of 6.e.
A precedent for this is when Objective-C was renamed to Swift, the latter went to version 1.0.
Since the old versions all have letters, and if the new versions don't have letters, we can special case for backwards compatibility that any 6.c or 6.d are ordered before 1.0 or any higher numbers we eventually get to.
If that idea of going to 1.0 is considered unpalatable, then I support 7.0 instead of 6.e, not because it is the 7th version, but because it is the next version after the 6.x we had before and so sorting would work right under unified rules.
Major version numbers are never supposed to indicate this is the Nth version, it is only about relative rank between existing versions.
A key thing we need to account for however is that we need a distinct version namespace from Perl 5, so that either that or Raku can use 1.0 or 7.0 or 30.0 or whatever and it would be trivial for a compiler to be given source in either language and be able to know what language it was given.
Sorry, I may be wrong... but Swift and Objective-C are 2 different languages...
Well Apple was certainly treating Swift 1 as the next version of what used to be called Objective C, a total substitution. Does anyone know otherwise, that newer versions of Objective C continued to be made and used by Apple after Swift came out?
@duncand That worked for Swift because there was no exiting code base to maintain compatibility with. We do have that base which already relies on 6.c/6.d.
I'm not a big fan of changing the versioning scheme. But since the overall support for this move is growing, I'd rather upvote for v7.0 option.
For those who worried about "there was no previous versions" issue – try finding Windows 6? Or Java 2,3,4? Can't recall right now, but I certainly knew an application which started from something higher than 1.x.
More than skipping, I'm worried about the syntax we're using. Because use v7; might be Perl's statement too. We need something more explicit, like use raku;, use raku:ver<7>;, etc.
More than skipping, I'm worried about the syntax we're using. Because
use v7;might be Perl's statement too. We need something more explicit, likeuse raku;,use raku:ver<7>;, etc.
I completely agree, this is the biggest issue.
I think the use of the word use for language versioning is a Perl-ism that we should deprecate. I would therefore propose a new statement, language, followed by a token indicating language and version:
language raku:ver<1.0>
comes to mind.
Additionally, I think the whole language handling needs to be generalized, as to easier allow other languages to be developed in module space. But that should probably be taken to a different issue.
No, I mean language, possibly even in uppercase: LANGUAGE. It should only occur once in every compilation unit, no need to huffmanize it.
On Samstag, 21. Dezember 2019 02:13:12 CET Darren Duncan wrote:
My preference is to actually go back to version 1.0 instead of 6.e.
Since the old versions all have letters, and if the new versions don't have letters, we can special case for backwards compatibility that any 6.c or 6.d are ordered before 1.0 or any higher numbers we eventually get to.
That would mean that the Version class would have this special casing, which would also apply to modules and anything else where Version objects are used. Or that we'd have to use a different class just for Raku versions and all toolchain parts would have to adopt this and keep this additional code forever. That's hardly good use of scarce engineering resources.
I'm also not convinced that the issue is actually worth solving. TEX does just fine with a versioning scheme that approaches Pi by adding digits. The very first version of the SUSE Linux distribution was 4.2 for obvious reasons. The world doesn't learn about major releases because they notice that some number changes, but because we put out press releases headlined "New Major Raku Release".
Changing the scheme does have more consequences than just a few adjustments in
rakudo and roast. What about use v6::inline; to embed Raku code in Perl 5
code?
I'm not sure Version would need special casing: the :ver<1.0> is just syntactic sugar for creating a Version object? The "raku" part would not be part of the Version object?
7 is even a worse idea for me because it maintains confusion with perl: perl deserve a major version for years and 7 makes perfect sense in this situation. raku is a new story so let's roll back to 3 as long as there is no technical reasons to avoid it. but someone proposed e: i love that too ... 21 major versions of raku with only one symbols could be nice and yes: e > 6
lizmat said:
I think the use of the word
usefor language versioning is a Perl-ism that we should deprecate. I would therefore propose a new statement,language, followed by a token indicating language and version:language raku:ver<1.0>
Yes, 100% this, and the "language" written out in full.
I will note as a tangent that for a meta-declaration format I use with my Muldis Object Notation data/code interchange format I use 2 such declarations called "syntax" and "model" rather than "language" such that the first declares what literal/concept syntax or "possible representations" we have in a more abstract sense, similar to the SQL standard, while the second declares what programming language data model types etc we expect each possrep to map to, the idea being that these 2 concepts are often separable, how to parse versus what you map the parse results to. (Technically there's also a 3rd such declaration called "script" which can be useful to explicitly disambiguate the text encoding in use etc.) Yes, I thought about this a lot.
eiro said:
7 is even a worse idea for me because it maintains confusion with perl: perl deserve a major version for years and 7 makes perfect sense in this situation. raku is a new story so let's roll back to 3 as long as there is no technical reasons to avoid it. but someone proposed e: i love that too ... 21 major versions of raku with only one symbols could be nice and yes: e > 6
This has nothing to do with Perl. We use 7 because it is numerically greater than the 6 Raku is already using. Also Perl is at like version 30 already; if they ever change their scheme from 5.X.Y it would make sense to continue at that same X.Y and not 7 or whatever.
This has nothing to do with Perl. We use 7 because it is numerically greater than the 6 Raku is already using. Also Perl is at like version 30 already; if they ever change their scheme from 5.X.Y it would make sense to continue at that same X.Y and not 7 or whatever.
so why did we use 6 ? this has something with the history of perl. if you want to brand raku as a new thing, please stop using historical schemes to decide about your versioning or your mascot.
No, we're not going to change the version backwards. If there are any changes to versioning, 7.0 is the only way it can realistically happen. It's a good thing, we can finally come up with something for minor-ish versions instead of having unversioned ever-changing errata branches (that by itself will likely require dropping unorthodox letters).
The world doesn't learn about major releases because they notice that some number changes, but because we put out press releases headlined "New Major Raku Release".
Yeah, that didn't really work when 6.c was released.
Look, I understand that using letters instead of numbers was TimToady's way of working around the whole thing with the "6" in "Perl 6" being interpreted as a version indicator rather than as a language indicator. So yes, one could go for full numerics in future versions of Raku.
On the other hand, having an "E" language indicator, does have some StarTrekky appeal.
Raku Language Level "E" has been released. It brings the following new features:...
No, we're not going to change the version backwards.
Certainly anything that happens has to have the version literals compare correctly, so the version literal of whatever new number we pick must compare greater than 6.d.
I've no problem with 7 personally, but to provide one other option for those not so keen on it: we could follow the C++ (and surely others) approach of using the year the version of the standard was released. Thus there's been C++11, C++14, C++17 - and of course, I can look at C++20 and know it's an upcoming version, because it ain't 2020 yet. So it we were to release a language version next year, it'd be Raku 20.
Also, with regard to the language keyword proposals, I'll ponder it some, but my initial feeling is that I'm not thrilled about another keyword. I think use is huffmanized about right. Also - admittedly a problem that goes away in some years but worth considering - it gives a poor error for those who have a Rakudo version that doesn't know about the new keyword, where it'd just get reported as an undeclared sub named language - as opposed to the rather more helpful message that you don't have a new enough compiler.
the only way it can realistically happen
Raku 20
OK, I stand corrected, that is also an option. I'm not sure if it's better to do it that way, but it's definitely a possibility.
I like year-based versioning, but I wonder what the C++ Standards Committee, and Raku developers should this become the version format, will do in the 22nd century when C++(21)13 is due. C++113? (It's remarkably convenient that this is the 21st century, and we can keep year-based version strings small for some time to come.)
No need to reach that far: C11 is already newer than C99. I could live very well with Raku 2020 - if we decide that we need to "solve" this at all.
While we can use dates as a basis for version numbers, they should still be fully qualified with simple comparison rules and have longevity and account for any likely scenario.
I propose a scheme like YYYY.X.Y.Z that is essentially https://semver.org but that the YYYY.X combined is the MAJOR and all trailing integers are optional (then treated as zero). How this would work is if no more than 1 version is released in a calendar year, the version is simply the 4 digits of the year, and the X/Y/Z are all implicitly zero. If we happen to release additional MAJOR versions in the same calendar year then we increment X, first to 1, and so on.
This scheme can also be used by modules/etc if they choose, its all just a meta-spec over general version objects we already have.
Use of full year would be a good option but apparently it will result in confusion with Rakudo versioning.
Use of full year would be a good option but apparently it will result in confusion with Rakudo versioning.
It shouldn't cause confusion though. Using full years for versions is a common enough generic thing. If we're worried about confusion about this then that should be fixed in some other way, such as appropriate documentation on both projects.
What I definitely don't want to see is 2-digit year based versions, that would be horrible.
Basing versioning on the Gregorian calendar is (at least at the moment) fairly universal and, as long as we allow for an arbitrary length of year, quite future-proof.
