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

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

scriplit commented 5 years ago

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

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

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

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

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

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

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

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

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

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

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

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

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

vrurg commented 5 years ago

For the record: the voting ends today.

nxadm commented 5 years ago

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

vrurg commented 5 years ago

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

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

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

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.