Problem-solving: Decision to be taken on Raku filename extensions.

[vrurg]

It is to be decided what filename extensions are to be used for Raku if language renaming happens.

[vrurg]

This is a followup to #101. Here we only decide what extensions are to be used. Proposals on using same extension for all file types and alikes are not welcome.

The bottom line of #101 is following:

Options

The base (script) extension is to be chosen of two options: wether it be .raku or .rk. Depending on this accompanying extensions could be:

• for .raku
  
  
  
  • .rakulib or .rakumod – TBD
  
  
  • .rakudoc - perhaps, everybody would agree
  
  
  • .rakutest – TBD, I didn't find any good option for tests in #101
  
  
• for .rk
  
  
  
  • .rkm
  
  
  • .rkd
  
  
  • no good option for test files.
  
  

Pros and Cons

• .raku
  
  
  
  • pros
    
    
    
    
    
    • guaranteed uniqueness and better recognizability.
    
    
    
    • less chances of concurring with other file types for editor support
    
    
    
  
  
  • cons
    
    
    
    
    
    • lengthy
    
    
    
  
  
• .rk
  
  
  
  • pros
    
    
    
    
    
    • shortness
    
    
    
  
  
  • cons
    
    
    
    
    
    • no good option for test files. The best one would be .rkt but it is taken by Racket.
    
    
    
  
  

Why?

The whole matter of renaming Perl 6 is about improving user perception of the language. While extensions is not the most important part of the process, they might play surprisingly negative role if poorly chosen. My popular example is Atom editor where perl5 package is disabled by perl6 for a very stupid reason: they both claim .t extension. As I remember, intelliJ IDE also has a problem with this respect as it doesn't allow changing a file type on the fly and have it strictly bound to the extension.

In the highly concurrent world of ours problems like these play because one could give up learning a new language only because he couldn't get good support from his favorite IDE. Say, we decide to go with .rkt for test files and a newbie would get to choose between either Raku or Racket.

Similar complications might cause us problems on popular services if they rely solely on extensions for determining file types.

What extensions to choose isn't in the list of the most important decisions on The Path to Raku. But the same time it's an irreversible one. I personally tend to choose carefully when there be no way back afterwards.

[vrurg]

And as a topic started I take the chance of expressing my own preference first. It would go for .raku. I consider it much cleaner option in all respects.

[Grinnz]

I would add that whether a distinct test file extension is needed at all is another decision that did not yet have consensus. (Not that I have any opinion either way, or that it would matter if I did)

Either continuing to use .t or reusing whatever extension is used for scripts would be two alternatives.

[vrurg]

My opinion on test extension is that the only people who could propose a radical change are those who develops testing tools and modules. @Leont, in particular.

[ugexe]

I still don't understand the need for this. We did not create a separate issue to vote on the name or other minor details -- one comes with the other and is thus part of it.

[AlexDaniel]

@ugexe I'm not following your point. This is just a ticket to have a dedicated discussion about extensions without cluttering the existing PR (which is already hard to follow).

[vrurg]

@ugexe based on Jonathan's comment, the decision would be made once and forever. The only other one-way decision is the rename itself. Looking at #101 we may conclude that the extension subject is rather controversial. The best way to resolve it is to vote.

[ugexe]

It appears controversial because it is incredibly bikesheddable. And since this is literally part of the other PR it belongs there.

Feel free to continue this. I'm just getting the impression problem-solving is turning into a prime example of death by committee.

[AlexDaniel]

This is a thread to discuss the extensions, so that we can adjust the main PR. Please don't bring unnecessary pessimism here.

[ugexe]

Yes, leave pessimism at the door. Wouldn't want anyone going against the grain 🙄

[AlexDaniel]

@ugexe in this discussion you're not going against the grain.

[ugexe]

@AlexDaniel in this discussion you're not convincing me of anything.

[vrurg]

@ugexe the whole point of this topic is just to vote. Get a minor decision on wether it be rakumod or rakulib, two other similar decisions – and choose. It would turn into bikeshedding if we chose to do so. Or we not.

BTW, it's rather for you to decide impartially on which of the two long module extensions is better.

[ugexe]

Bike shedding is the tendency of unimportant issues to receive undue attention because the barrier of entry to give an opinion on the subject is extremely low or non-existent.

[AlexDaniel]

OK, this ticket is for discussing the filename extensions. We need to choose some good extensions because https://github.com/perl6/problem-solving/pull/89 is currently blocked by it. It is good to have a separate ticket because following discussions on a PR was proven to be difficult. Once we have enough info here, the main PR will be adjusted.

Please file a separate ticket for any other matter.

[AlexDaniel]

Hypothetically, it's also possible to have both short and long versions. It's not uncommon, for example .markdown and .md. This does create a problem if a module has both Foo.rkm and Foo.rakumod files (so which one has the priority?), but at the same time it's unlikely that a module author would do something like this, so maybe it's not that big of an issue (after all we did have both .pm and .pm6, and while it's painful, it does sorta work).

[tony-o]

Move forward with the .raku[mod|doc|test] extensions and let's move on.

[hythm7]

My opinion on this is:
.raku for modules.
No extension for scripts and tests. ( unless it is required for MS Windows, Then use same extension .raku ).

[AlexDaniel]

@hythm7 you're free to use no extension for scripts, but it seems to be needed. Also, as previously discussed, we're not going to use the same extension for scripts and modules.

[vrurg]

As I don't want this to take too long and turn into another round of bikeshedding, lets do it this way:

• do not discuss but vote
• my next three comments would represent three options to choose of
• the options will contain final and non-discussable variants of extensions. The only changes allowed are:
  
  
  
  • for modules: by @ugexe
  
  
  • for test files: by @Leont
  
  
  • by @jnthn to any except for the base extensions (or otherwise this all wouldn't make any sense)
  
  
• a like (the thumb up) means a vote for an option. No other "like" is taken into account.
• please, don't vote two options at once. Such votes could be excluded from total count.
• the voting is in effect for three days with the first day starting on Sep, 17. In Europe it is effectively "today" now, as I'm writing this
• the voting result is to be considered by @jnthn and _it is up to him to decide wether to change the renaming PR with accordance to the public opinion or not_. He could as well make his decision before to the above specified deadline.

UPD Option 4* has been added to the voting.

[vrurg]

Option 1

.raku, .rakumod, .rakudoc, .rakutest

[vrurg]

Option 2

.rk, .rkm, .rkd, .t

Test file could be reconsidered later, as it already happened with .t6.

[vrurg]

Option 3

Both option 1 and 2 to be supported as proposed by @AlexDaniel above.

[japhb]

Sorry, I'm not trying to bikeshed, but for option #2, where was the decision not to use .rt? I thought I saw someone mention that one, but then I lost track of where it was decided against. (I personally felt it was a reasonable compromise to avoid stomping on .rkt, but again I'm not trying to bikeshed, just to figure out where I got lost here.)

[vrurg]

@japhb the discussion was a bit scattered over a couple of places. .rt stands for RealTime Player files. Could though be considered with care because it would barely be a file format known to editors and thus won't cause conflicts. But I'm not sure about it, anyway.

UPD BTW, what makes things worse is that .rt is RealText format. In other words, I was wrong and editors could know and support it. Even though unlikely a lot of them do.

[AlexDaniel]

@japhb it's a fair question. @jnthn wanted something that has a prefix (like “.rk*”), which is why we started to drift away from “.rd” for docs. But .rkt is a real problem so I'm not sure if this idea is really useful…

[duncand]

In my opinion, the extra few letters in the longer extensions are a complete non-problem, when you consider how often they are typed and how long the rest of the filename/path/etc they are part of already are, so the raku form wins in every important metric.

[vrurg]

BTW, we played a game of "imagine your file with new extensions" on IRC. Perhaps it worth visualizing how things would look:

bin/myscript.raku
lib/MyModule.rakumod
doc/MyModule.rakudoc
t/00-test.rakutest

bin/myscript.rk
lib/MyModule.rkm
doc/MyModule.rkd
t/00-test.t
t/01-test.rt # Ok, what if...

[shishini]

for the .rk option
may i suggest .rktst for the test file
its .rakutest - all the voyelles (a,e,i,o,u,y)

[duncand]

@vrurg I believe the rk option can avoid conflicts with Racket et al if it isn't strictly limited to rk plus 1 letter, eg if 2 letters is ok. To be specific, I suggest rktt for tests which can also evoke the t/*.t of old. It shouldn't be a problem to have say rk/rkm/rkd/rktt if that's all it is. I still prefer the raku stream but a change like this can make the rk stream easier to live with.

[vrurg]

For the record: I'm not going to change the options except for the situations stated in the voting rules. But any reasonable proposal expressed in comments could be considered later.

.rktt looks promising to me. Though I didn't check yet if it's used somewhere.

[duncand]

My basic Google search found nothing using .rktt.

As for changing the existing options, I expected you wouldn't but I'm assuming the 3 named individuals in the voting rules might do so.

[lizmat]

To prevent any ambiguity, we need to move our thinking out of the 8:3 mindset: I therefore strongly support @tony-o:

Move forward with the .raku[mod|doc|test] extensions and let's move on.

[duncand]

Adding your thumbs up vote to Option 1 will make more sure that support gets counted.

[jnthn]

@jnthn wanted something that has a prefix (like “.rk*”), which is why we started to drift away from “.rd” for docs. But .rkt is a real problem so I'm not sure if this idea is really useful…

Yes, I really liked the idea of a prefix, but we really can't do .rkt. I since realized that we could, however, pick the prefix ra instead, which gives actual words (and thus a bit easier to say out loud than listing initials):

• .rat - tests rat out problems
• .rad - a well-documented module is really rad
• .ram - feeling sheepish about that huge script? Ram some of the code in a module.

None of which seem to have any existing programming-language-related usage. For a program ("stop saying script!" :-)), there's also .rap (let the code flow).

[duncand]

What @jnthn said has some appeal, and may make some wonder why ra wasn't even mentioned before in favor of rk.

I do somewhat like the idea of rap such that ALL extensions are a common prefix plus 1 letter. It kind of rubbed me the wrong way that programs would have the base extension when modules might be the form most code is actually written in, though I can understand why it would be done.

However, 1 big issue I see with those options is that ra and ram etc were widely used multimedia file formats connected with RealPlayer, and it is very likely that various modern multimedia programs like VLC will try and play them.

Actually I tested it: I have VLC installed on my Mac and double clicking a .ram file tries to open it in VLC.

This is considerably worse than rk being an old archive file format; the RealPlayer files are likely to be quite widely distributed still.

I still think raku is much better extension base.

[lizmat]

FWIW, on MacOS .ram is indeed associated with RealPlayer, and attempts to play it with RealPlayer when opening it. Although MacOS doesn't come with a RealPlayer.

Perhaps .ral would be better, for RAku Library. Or .rai for RAku Interface?

[lizmat]

I still think raku is much better extension base.

Which would make .rakut, which is at least in Dutch, weird, and sounds like Racket.

[duncand]

Just throwing this out there: rakup, rakum/rakul, rakud, rakut.

[vrurg]

@jnthn Shall I add Option 4 and restart the vote? Though RealTime associations put me very much uncertain about .ra family.

[AlexDaniel]

People should feel free to change their reactions. This is not the same voting that we do in the problem-solving repo anyway, I see reactions as merely an indication of which extensions people will prefer to use. I think @jnhtn and @lizmat will decide how to adjust the main PR.

[vrurg]

@AlexDaniel the point is to make clear it is a 4th option. Wouldn't it be bound to RealTime I'd added it already.

[borisdaeppen]

The .rk-line always felt so "klingon" to me (meaning "hard", "rough", "tongue-twister").
Both for the eyes (a lot of sharp corners) and mouth (only hard consonants).

Just because of this I'm positively surprised about the .ra idea.

[tmtvl]

.rat is already used for PICS Web rating system implementations, though they are not very popular for W3C standards.
.rad is used by the Source engine and files are formatted as XML.

[duncand]

@jnthn @vrurg There are other subsets of Raku we didn't consider yet.

May I suggest ru (for RakU) as the base, assuming there isn't some negative connotation.

From what I saw, only run is already used by something; ru itself is also available.

So then we have rup, rum/rul, rud, rut for extensions.

Alternatively, rl* for Raku Language.

So then we have rlp, rlm/rll, rld, rlt for extensions.

I suggest that https://www.reviversoft.com/file-extensions/?char=r is useful at a glance about options, assuming it is reasonably thorough.

EDIT: Then again, http://www.pcpitstop.com/libraries/fileextension/search.asp?search=R is a lot more thorough.

I still prefer biting the length bullet and having the whole raku though; it can still be combined with single characters.

[duncand]

Another variation is rak (RAKu) as the common base. Then we can use raku for main programs and also rakm/rakl, rakd, rakt for others. Personally this looks kind of like pirate talk, eg "red rackhams treasure".

[vrurg]

@duncand .ru and .rak are both rather far-fetched. Human brain won't really bind ru to Raku and thus won't be easily creating associative link. rak is just one letter away from raku which also makes little sense in choosing it.

[vrurg]

For test files I'm permanently coming back to .t.rk variant – a slight development of _test suffix proposed in #101:

00-mytest.t.rk

It doesn't really makes me all happy, but it serves for two purposes at once: it clearly identifies file type; and it clearly declares the file to be a test.

[niner]

I very much like the .t.rk or .t.whatever-extension-we-chose-for-programs idea. It resolves the ambiguity with .t files and eliminates the chance of an oversight in tools which may miss the test file extension while still marking test files as such.

[Mekk]

1. What about .trk (memo: test rk) for tests?

2. Of funny note, .rk is somehow related to .pl (r follows p, k precedes l – at least in alphabets where q is not used)

[vrurg]

@Mekk .trk is in use by GPS tracking data.

[scriplit]

Perl 6 invented twigils, nobody would be surprised if Raku would now introduce twilexts ;)
bin/myscript.raku
lib/MyModule.m.raku
doc/MyModule.d.raku
t/00-test.t.raku

[vrurg]

@scriplit that was the second thing on my mind, but I rejected it because it is unlikely to be welcomed by some. Anyway, if we go this way, I would rather consider .rk then and have:

bin/myscript.rk
lib/MyModule.m.rk
doc/MyModule.d.rk
t/00-test.t.rk

Also twextensions would ease adding new file types in the future if needed. Though they would have to be syntax-compatible with Raku itself as to not drive crazy editors which rely on the last extension exclusively – if there're any of the kind.

[duncand]

Oh, please, can we do that? Twexts for everyone!

The main extension indicates the actual format of the file and how to parse/interpret it (the Raku grammar), which is the same for all the use cases we've been discussing.

The sub-extension provides more semantics on the main purpose of the file (app/lib/doc/test).

This approach means we minimize actual footprint and combinations.

Exploiting this, I recommend we reserve BOTH rk and raku main extensions and let people use what they want similar to the md/markdown dual; each one can share the same sub-extensions.

I also recommend for parity that we have an official sub-extension for main programs, eg p/a for program/app, but the sub-extension is optional and implicitly means main if absent.

[tony-o]

(and why I originally proposed a single unified extension).

As discussed ad nauseum, a single unified extension is a headache that's not well thought through.

@vrurg can we please lock this and start a vote? Closing the voting and reopening it is not going to get a decent vote (a lot of people have already voted). Further, if this is really holding up the referenced PR this bike shedding is not useful and holding up more important tasks.

Edit: formatting.

[duncand]

@tony-o I'm not proposing a unified extension, that ship has sailed. The twext option is still multiple extensions, but a different format.

[duncand]

@tony-o The voting already started yesterday and never stopped. And your proposal is winning with 10 thumbs-up votes. This discussion is on the side and doesn't take away from the voting.

[vrurg]

@vrurg can we please lock this and start a vote?

The voting is currently active. Because it has rather advisory status (meaning it's results are not decisive and only provide info for @lizmat and @jnthn to make up their mind), there is no point in blocking discussion because it might result in some fresh new ideas to be taken into account.

In either case, Jun 19 is the last voting day when it all ends and we proceed with the main PR.

[nxadm]

Option 1

_.raku_, _.rakumod_, _.rakudoc_, _.rakutest_

What about having extensions of the same length for non script files? Shells and other programs using fixed width fonts will look a lot prettier...

foo.raku
foo.rakulib
foo.radudoc
foo.rakutst

[AlexDaniel]

Shells and other programs using fixed width fonts will look a lot prettier...

But why does that matter? Strings of different length are easier to distinguish.

[nxadm]

Shells and other programs using fixed width fonts will look a lot prettier...

But why does that matter? Strings of different length are easier to distinguish.

I think you underestimate the people with a soft form of OCD in programmer's circles.

[AlexDaniel]

soft form of OCD

Should we care? And what about mild forms of impaired vision :P

Anyway, test files are unlikely to be near other files often, and if that happens I don't mind the other files to stand out a bit.

[nxadm]

soft form of OCD

Should we care? And what about mild forms of impaired vision :P

Anyway, test files are unlikely to be near other files often, and if that happens I don't mind the other files to stand out a bit.

And these?

foo.raku foo.t.raku foo.rakulib foo.radudoc
Too incoherent? Just right?

[vrurg]

@nxadm I think "incoherent" is the right word for the case.

[vrurg]

For the record: the voting ends today.

[nxadm]

(@vrurg, don't forget about time zones...)

[vrurg]

@nxadm I remember. I think it would be ok to close at 00:00 PST. Though considering the current activity, it's unlikely to see any more votes.

[nxadm]

Yes, just to be sure. It looks like who wanted to vote on this issue already did. (I abstained because I am fine with whatever is chosen.)

[vrurg]

The voting is over. The bottom line:

1. Option 1: 11
2. Option 3: 7
3. Option 4: 5
4. Option 2: 2

Interestingly enough, twextensions got 6 votes even though they were not on the list. Would they be there my vote would go for them too.

Anyway, I think we could say that community has made its choice and we can proceed further with #89.

[duncand]

As a status update, Liz has just updated the pull request https://github.com/perl6/problem-solving/pull/89 to use the raku/rakumod/rakudoc/rakutext options, thus resolving this issue.