On the other hand outsiders would immediately recognize a Perl as being a different kind of Perl than the Perl5 they associate the name Perl with today due to the C->C++ relationship. My own preferred name would be Perl** to avoid the oo assumptions.
Anyway, as long as it breaks the Perl 5 deadlock I'll support any name.
]]>At least it haven't made it's way into the perl porters mailing list thread (yet!).
I guess that the only way the language would possibly be renamed is if someone forks the current implementation and is successful enough to bring the community with it. The biggest problem I see with that is that there are only a handful of people that knows the perl core source code well enough to successfully fork it and they have their hands full with the core as it is. And in all likelihood they are not interested in forking the core either.
On top of that the fork would , IMHO, need the blessing of Larry to have a perl language family name (e.g. perl++ if it includes better OO from the start) instead of a completely unrelated name.
]]>That only leave the renaming option open. The renaming option “Perl 5” -> “Perl5” I suggested earlier would probably only work inside parts of the Perl 5 community so we can forget about that.
At the same time we want to keep Perl as Perl, so I don’t believe in the Chocolate/Citrus/DWIM/Strawberry/… Perl strategy either, at least not as a version bumper strategy. I guess we could fork it “the C way”, i.e by naming it Perl++ or Perl# even though it feels like a cheap marketing trick to mimic the C variant naming schemes.
]]>The version number matters because it’s a mental barrier for breaking backwards compatibility and cleaning up the core. As long as we’re on major version 5 there will be a strong opposition against breaking backwards compatibility so we need to find a way to step the major version to get rid of the mental block.
]]>What I meant was that the mop and the signatures should be included in some future release of Perl 7, not specifically in 7.0. All the things that breaks backwards compatibility needs to be in the first release though.
As to what numbering scheme to use: My problem with yearly numbers is not that it can be look like we’re breaking backwards compatibility, it’s that it will not be possible to tell when we do.
The only scheme that I can think of that will change that is to combine the suggested schemes as follows:
Rename the language from Perl to Perl5
Set a new major version E.g. v20 and keep it until we break backwards compatibility again
Use the release year as minor version
Keep the patch version scheme as today.
I.e the releases would be called:
Perl5 v20.2014.0 First release according to this scheme
Perl5 v20.2014.1 first patch
Perl5 v20.2015.1 next minor release
Perl5 v22.2017.0 next major release?
I don’t know how well this would play out marketing wise though, but I think we could get away with it without stepping very hard on Larry’s toes.
]]>In my opinion a few major things needs to be added/changed to motivate a new Perl major version and at least some break backwards compability:
A mop in core perl with Stevan Little's attempts as a blueprint (blessed references still supported though)
Function signatures instead of prototypes
A real language specification
Optionally these things would be good to have too, but they can be added in later releases if currently conflicting functionality is dropped or moved into optional modules.
Optional typing
Lightweight threads
Simplified smart match operator
Multi-method support (same function with different signatures)
Class-based exceptions
In essence I think we require major new functionality and a break in backwards compatibility at this stage to go for Perl 7
]]>