I had a related thought. We want Perl 6 to be the best it can be out of the
gate when it is declared production ready at Christmas or whatever. If it is
better for the default to be that parameters must be defined where not
explicitly declared otherwise, then that is what Perl 6 should specify, and it
doesn't matter about the 390+ modules that exist now. Perl 6 is supposed to be
a break it all at once release, and this situation is no different. Having :D
being default seems right to me, that would seem to huffman code for the safer
behavior which users most likely want by default. -- Darren Duncan
On 2015-10-13 1:52 AM, Richard Hainsworth wrote:
Following on the :D not :D thread, something odd stuck out.
On 10/13/2015 03:17 PM, Moritz Lenz wrote:
<snip>
But hopefully none of them breaking backwards compatibility on such a large
scale. The last few backwards incompatible changes still cause pain in the
ecosystem. We have 390+ modules, and hand-waving away all trouble of
maintaining them seems a bit lofty.
<snip>
Surely, the idea of keeping the release number below 1.0 is to warn early
adopter developers that code is subject to change and thus in need of
maintenance?
Seems strange that after so long and "Christmas" is finally coming up that
Rakudo 1.0 is going to be associated with modules that do not comply with the
"standard". So if :D is the default specified by the standards, then all modules
should be expected to conform to that standard when V1.0 comes out.
It does not matter really what the standard actually is, :D or not, so long as
what is defined to be the standard is adhered to. Perl6 gives huge flexibility
to developers to change standard for themselves, but surely there should be some
common 'starting' ground, and modules for general use should adhere to it.
When the language and implementation were being co-developed, it was reasonable
to expect that different modules would have different states of compliance. But
surely V1.0 is a different sort of milestone?
'Hand-waving' all the trouble of maintaining the modules surely is not the
issue. Ensuring that the modules comply with the standard set for Perl6 as
implemented by Rakudo V1.0 is a reasonable expectation for anyone using the
Rakudo version of Perl6 going forward.
Even if there is an argument that I have missed in the above about the need for
modules to adhere to the standard prescribed by the Perl6, would it not be in
the interests of PR around Perl6 for the very first V1.0 implementation to be
accompanied by modules that have been brought as close to the standard as
possible? These modules will help future developers to understand how to use the
language.
