For me, the .code method makes more sense to me than .perl or .raku. It's name is more universal and therefor more easily understood. There is no need to be self referential here.

👍 on .code. But we need to add changing the already existing .code methods to something else. It's actually only in two classes, so it wouldn't be a big deal.

I agree with @nxadm. .code just feels better to me, but the fact that .code method exists in other classes is kinda unfortunate :S

Yeah, .code is nicely generic, I like that too. But that is why a .code attribute is meanwhile also used by module authors (← contains a sizable amount of false positives) to denote:

• HTTP status or native library error codes,
• BSON type byte,
• XML source code,
• callbacks.

So .code vs. .raku vs. … also needs to be weighed against the

[...] existing scripts continue to work without change

part in "Technical Changes". .code means some unbitrotting, .raku doesn't.

Clearly should be .EVAL-able ;-).

IRC channels?

Thanks @lizmat for writing that.

wrt. the mascot, Camelia has p6 drawn on it, wondering if it should be replaced with raku or rk.

r   u
 a k

Most people miss the P6 letters anyway, so it could be left there for historical reasons. If it's decided to remove the P6 reference, I don't see the need to add the raku letters. Less is more.

What about “use v6”?

Will it be Raku v6.d or Raku vd or Raku v1.d or what?

What happens to NQP, will it become NQR?

@hythm7 :

wrt. the mascot, Camelia has p6 drawn on it, wondering if it should be replaced with raku or rk.

r   u
 a k

I was the one who has the mascotte made into 1,000 copies of the stuffed toy and I do not want to explain that it has cost a lot of time, energy, frustration and money, and since I still have over 500 of them, I am not planning on having another batch made. Not for the foreseeable future. In case of a namechange, I think I just have to throw them all away, burn them, turn them into compost, whatever. :-(

I think no changes required for the mascot even after name change. There is a nice suggestion mentioned above to leave the mascot as is and the p 6 "could be seen as lasting tribute (easter egg) to the origin of Raku".

For the reddit community it looks like raiph already has https://www.reddit.com/r/raku/ (appears to have briefly been about pottery) secured.

EDIT: Meaning that it is under control of this community. It was barely used and raiph convinced them to transfer it over.

I was the one who has the mascotte made into 1,000 copies of the stuffed toy and I do not want to explain that it has cost a lot of time, energy, frustration and money, and since I still have over 500 of them, I am not planning on having another batch made. Not for the foreseeable future. In case of a namechange, I think I just have to throw them all away, burn them, turn them into compost, whatever. :-(

No, you don't. Most likely Camelia will not change. And if it does, you'll have collection items that will interest many hackers.

What happens to NQP, will it become NQR?

Not Quite Ready.

The documentation format is also called Pod 6, so it should probably be coordinated with whether that name is changed.

My thoughts on that, but not much of an opinion either way: Pod 6 is much more like a revision of Pod and is very similar in use and appearance, there is an active attempt at some compatibility, and it's referred to as just Pod in various places. But it is not 100% compatible. It's just not that important comparatively, you currently don't find much about either Pod or Pod 6 on google without using the language name, and nobody is ever really in a situation to discover what Pod or Pod 6 are without the context of the languages. So the only reason to do such would be for consistency in naming or to better distinguish itself from Pod in the future.

.rkpod?: it's pod after all, a format unknown and unpopular outside of the Perl world.
.rkdoc? This would make more sense if it was md based as expectations would be to be read on the console with less or cat without a pod parser in your head.

Ugh, no. Let's keep Pod6. It's a slang, included but different from Perl 6/Raku. Are we going to call the regex slang rkegex? Or the quote slang rkuote? It's not big deal. It does not have Perl in the name, it's just a six-ish version of plain old documentation.

.rkp or .rp?

pod6 sound very out of place to me for a language called raku. Pod is werid, the 6 makes it even weirder. (Now I think about it is even weird for Perl 6.)

Every implementation can supply a raku executable (it's actually an implementation of raku). Package managers and the 'alternatives' system can the select which one will be the first in PATH. This is pretty much how Java and python implementations work.

My point was to make the life of package managers easier.

We can add a whisker to the p to make it look like an R and delete a part of the 6 to make it look like a k.

I ❤️ Camelia; let's keep her as she is, as a reminder of where she came from :)

@karenetheridge That's the plan. No changes to the wing pattern either :-)

@vrurg So, I see it like this. Currently we don't have proper versioning of the language, and instead we use -errata branches (which are changing all the time, even if the fixes are minor). That doesn't sound right to me, especially if we subscribe to the idea that there could be more than one implementation. So in the end we might need minor versions, or something, and I don't like any short-sighted attempts to change the situation without taking other things into account. As for the letters, if we do something like 6.d.2, then question is why not just go full semver, and if so, then why are we using letters at all (even if it's allowed by semver, nobody really does it the way we do).

This turns into a wider discussion. I'll open a new topic on this.

.rt?

.rt reminds of RealTime Player. Yet, .tr follows the patter of .t6. But that's very minor question, I just wanted it to be mentioned, not resolved yet. :)

.t is a funny extension. It is not perl-specific to begin with - it can technically be any language that is given in the shebang or by the program that is expected to run them. But Perl and Raku do seem to be highest users of it. The only harm of reusing .t in my opinion is that editors and GitHub have a hard time classifying what language they belong to. Personally I have no qualms with multiple languages using .t, provided they are okay with that potential problem.