search

Raku / problem-solving

🦋 Problem Solving, a repo for handling problems that require review, deliberation and possibly debate
Artistic License 2.0
70 stars 16 forks source link

Decision to be taken on Raku filename extensions. #106

Closed vrurg closed 5 years ago

vrurg commented 5 years ago

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

vrurg commented 5 years ago

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:

Pros and Cons

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

@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 commented 5 years ago

@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 commented 5 years ago

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 commented 5 years ago

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

ugexe commented 5 years ago

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

AlexDaniel commented 5 years ago

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

ugexe commented 5 years ago

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

vrurg commented 5 years ago

@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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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

hythm7 commented 5 years ago

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 commented 5 years ago

@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 commented 5 years ago

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

UPD Option 4* has been added to the voting.

vrurg commented 5 years ago

Option 1

.raku, .rakumod, .rakudoc, .rakutest

vrurg commented 5 years ago

Option 2

.rk, .rkm, .rkd, .t

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

vrurg commented 5 years ago

Option 3

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

japhb commented 5 years ago

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 commented 5 years ago

@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 commented 5 years ago

@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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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

duncand commented 5 years ago

@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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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

jnthn commented 5 years ago

@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):

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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

vrurg commented 5 years ago

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

AlexDaniel commented 5 years ago

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 commented 5 years ago

@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 commented 5 years ago

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 commented 5 years ago

.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 commented 5 years ago

@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 commented 5 years ago

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 commented 5 years ago

@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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

  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)