Re: Exploit the versioning (was Re: Backwards compatibility and release 1.0)

[yary]

Short answer: everything must declare which semantics it expects-
everything in Panda/CPAN at least. And we already knew it, just need
to do it.

Full post: This thread points to a bigger problem, which has a
solution that is both cultural and technical.

Perl5 has a colossal code corpus, humbling in its pervasiveness. Perl
culture understands the value of backward compatibility to keep that
code working as the language evolves and the interpreter improves;
Perl-porters master the compatibility dance and pay for it with
cognitive complexity.

Perl5 has a tension between moving forward and keeping all existing
code running as it was first written. The backward-compatibility
contract is beneficial to the community, and yet it is also friction,
drag on the perl interpreter's progress.

In Perl6 culture, it's time to also adopt the ethic of forward
compatibility where each module states exactly what Perl6 semantics
its coded for. This is not a new idea, S11 says it: "modules are also
required to specify exactly which version (or versions) of Perl they
are expecting to run under, so that future versions of Perl can
emulate older versions of Perl"

That's the cultural part of the solution: we need to start putting
"use 6.0.0" at the start of our code now. The technical part of the
solution is for post-Christmas Perl 6.0.1 to respect that declaration
and "do the right thing."

And more immediately, the community fix is to get the word out; the
technical fix is to s/use v6;/use v6.0.0;/ for everything in Panda
that doesn't get the message by the release date. The old way "use
v6;" means "use any Perl6" and is what got us here: "6.*" is against
the spirit of "exactly which version (or versions) of Perl they are
expecting to run under."

... As for the specific issue of to grin widely or flatly, to :D or :_
defaultly, I'll defer discussing until 6.0.1.  (Earlier I posted a
more specific answer to Darren only; this post is more robust.)

Re: Backwards compatibility and release 1.0

[Moritz Lenz]

On 10/15/2015 10:47 AM, Smylers wrote:

Moritz Lenz writes:


On 10/13/2015 10: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:


We have 390+ modules, and hand-waving away all trouble of
maintaining them seems a bit lofty.


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?


... a large percentage of the module updates are done by group of
maybe five to a dozen volunteers. ... 5 people updating 70% of 390
modules. Modules they are usually not all that familiar with, and
usually don't have direct access. So they need to go through the pull
request dance, waiting for reaction from the maintainer. In short, it
sucks.


Thanks for the explanation, Moritz. That does make sense.

I'm still a _little_ uneasy because that sounds a bit like the
explanation of why Makefiles have to use tab characters:

   I just did something simple with the pattern newline-tab. It worked,
   it stayed. And then a few weeks later I had a user population of about
   a dozen, most of them friends, and I didn't want to screw up my
   embedded base. The rest, sadly, is history.

 — Stuart Feldman http://stackoverflow.com/a/1765566/1366011


The problem is, that with this kind of argument one can defer the 
declaration of a "stable" version indefinitely.


May I remind everybody that we want a stable release this Christmas?

Cheers,
Moritz

Re: Backwards compatibility and release 1.0

[Elizabeth Mattijsen]

> On 15 Oct 2015, at 12:57, Mark Overmeer  wrote:
> 
> * Elizabeth Mattijsen (l...@dijkmat.nl) [151015 10:43]:
>> FWIW, I’m with FROGGS on this.
>>  use variables :D;
> 
> In the first response to this message, Moritz spoke about
> use invocant :D;
> and use parameters :D;
> 
> Three different things?

There are actually 4 different default setters:

use variables :D;# works, e.g. ‘my Int $a = 42’
use attributes :D;   # works, e.g. ‘has Int $.a = 42’
use invocant :D; # parses, does not work yet, e.g. method a(Int:) {} # 
Int:D:
use parameters :D;   # parses, does not work yet, e.g. sub a(Int $a) {}  # Int:D


>> at the top of the scope of your code, and then you’re set.  I admit
>> it feels a *little* like the “use strict” boilerplate of Perl 5.
> 
> It is.
> 
>> On the other hand, I think by just specifying a type *without* smiley,
>> is already so much better than the situation in Perl 5 that the lacking
>> strictness of :D will not be needed much to catch programming / garbage
>> in type of errors anyway.
> 
> Much better, of course.  Programming languages are used by people
> of different taste.  Some may find "much better" enough, other people
> want more.

And sometimes less is more  :-)



Liz

Re: Backwards compatibility and release 1.0

[Elizabeth Mattijsen]

> On 15 Oct 2015, at 11:06, Tobias Leich  wrote:
> Am 15.10.2015 um 10:47 schrieb Smylers:
>> Moritz Lenz writes:
>> 
>>> On 10/13/2015 10: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:
> We have 390+ modules, and hand-waving away all trouble of
> maintaining them seems a bit lofty.
 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?
>>> ... a large percentage of the module updates are done by group of
>>> maybe five to a dozen volunteers. ... 5 people updating 70% of 390
>>> modules. Modules they are usually not all that familiar with, and
>>> usually don't have direct access. So they need to go through the pull
>>> request dance, waiting for reaction from the maintainer. In short, it
>>> sucks.
>> Thanks for the explanation, Moritz. That does make sense.
>> 
>> I'm still a _little_ uneasy because that sounds a bit like the
>> explanation of why Makefiles have to use tab characters:
>> 
>>  I just did something simple with the pattern newline-tab. It worked,
>>  it stayed. And then a few weeks later I had a user population of about
>>  a dozen, most of them friends, and I didn't want to screw up my
>>  embedded base. The rest, sadly, is history.
>> 
>>— Stuart Feldman http://stackoverflow.com/a/1765566/1366011
>> 
>> Though the important difference is that invisible whitespace characters
>> that some editors don't even let you type are particularly
>> beginner-hostile, whereas allowing undef arguments where they don't make
>> sense (and hence where callers don't generally try supplying undef) is
>> something that many Perl 5 programs have been doing for years with no
>> widespread harm.
>> 
>> Cheers
>> 
>> Smylers
> Btw, In my opinion the current model about :D etc is very correct. I
> don't see any need to change the
> defaults as how type objects or their definedness is implementet.
> Changing for example the params
> to mean Int:D by default when one writes Int is something you have to
> explain a lot. And in fact it is a lie.
> There are some basic rules about Perl 6 like TIMTOWTDI and DRY, but
> there is also a rule about "All is
> fair if you predeclare". But if I don't predeclare that I mean Int:D by
> writing Int, then the compiler is
> not allowed to change the meaning of what I wrote.

FWIW, I’m with FROGGS on this.

Because Perl 6 has gradual typing.  Going automatically from Int to Int:D, 
doesn’t feel gradual for me.  If you want this behaviour in your code, it is as 
easy as adding a:

  use variables :D;

at the top of the scope of your code, and then you’re set.  I admit it feels a 
*little* like the “use strict” boilerplate of Perl 5.  On the other hand, I 
think by just specifying a type *without* smiley, is already so much better 
than the situation in Perl 5 that the lacking strictness of :D will not be 
needed much to catch programming / garbage in type of errors anyway.


Liz

Re: Backwards compatibility and release 1.0

[Tobias Leich]

Am 15.10.2015 um 10:47 schrieb Smylers:
> Moritz Lenz writes:
>
>> On 10/13/2015 10: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:
 We have 390+ modules, and hand-waving away all trouble of
 maintaining them seems a bit lofty.
>>> 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?
>> ... a large percentage of the module updates are done by group of
>> maybe five to a dozen volunteers. ... 5 people updating 70% of 390
>> modules. Modules they are usually not all that familiar with, and
>> usually don't have direct access. So they need to go through the pull
>> request dance, waiting for reaction from the maintainer. In short, it
>> sucks.
> Thanks for the explanation, Moritz. That does make sense.
>
> I'm still a _little_ uneasy because that sounds a bit like the
> explanation of why Makefiles have to use tab characters:
>
>   I just did something simple with the pattern newline-tab. It worked,
>   it stayed. And then a few weeks later I had a user population of about
>   a dozen, most of them friends, and I didn't want to screw up my
>   embedded base. The rest, sadly, is history.
>   
> — Stuart Feldman http://stackoverflow.com/a/1765566/1366011
>
> Though the important difference is that invisible whitespace characters
> that some editors don't even let you type are particularly
> beginner-hostile, whereas allowing undef arguments where they don't make
> sense (and hence where callers don't generally try supplying undef) is
> something that many Perl 5 programs have been doing for years with no
> widespread harm.
>
> Cheers
>
> Smylers
Btw, In my opinion the current model about :D etc is very correct. I
don't see any need to change the
defaults as how type objects or their definedness is implementet.
Changing for example the params
to mean Int:D by default when one writes Int is something you have to
explain a lot. And in fact it is a lie.
There are some basic rules about Perl 6 like TIMTOWTDI and DRY, but
there is also a rule about "All is
fair if you predeclare". But if I don't predeclare that I mean Int:D by
writing Int, then the compiler is
not allowed to change the meaning of what I wrote.

That said, if there was a change that justifies breaking a lot of stuff,
I'm for it. But here it is certainly
not the case.

--
Tobias

Re: Backwards compatibility and release 1.0

[Smylers]

Moritz Lenz writes:

> On 10/13/2015 10: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:
> > >
> > > We have 390+ modules, and hand-waving away all trouble of
> > > maintaining them seems a bit lofty.
> > 
> > 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?
> 
> ... a large percentage of the module updates are done by group of
> maybe five to a dozen volunteers. ... 5 people updating 70% of 390
> modules. Modules they are usually not all that familiar with, and
> usually don't have direct access. So they need to go through the pull
> request dance, waiting for reaction from the maintainer. In short, it
> sucks.

Thanks for the explanation, Moritz. That does make sense.

I'm still a _little_ uneasy because that sounds a bit like the
explanation of why Makefiles have to use tab characters:

  I just did something simple with the pattern newline-tab. It worked,
  it stayed. And then a few weeks later I had a user population of about
  a dozen, most of them friends, and I didn't want to screw up my
  embedded base. The rest, sadly, is history.
  
— Stuart Feldman http://stackoverflow.com/a/1765566/1366011

Though the important difference is that invisible whitespace characters
that some editors don't even let you type are particularly
beginner-hostile, whereas allowing undef arguments where they don't make
sense (and hence where callers don't generally try supplying undef) is
something that many Perl 5 programs have been doing for years with no
widespread harm.

Cheers

Smylers
-- 
http://twitter.com/Smylers2

Re: Backwards compatibility and release 1.0

[yary]

On 10/13/2015 03:17 PM, Moritz Lenz wrote:
>... We have 390+ modules, and hand-waving away all
> trouble of maintaining them seems a bit lofty.
> ... a large percentage of the module updates are done by group of
> maybe five to a dozen volunteers. ... 5 people updating 70% of 390
> modules. Modules they are usually not all that familiar with, and
> usually don't have direct access. So they need to go through the pull
> request dance, waiting for reaction from the maintainer. In short, it
> sucks.

The idea is to make the maintenance one-time and as minimal as
possible. In the "Exploit the versioning" thread Darren D & I advocate
changing the version declaration at the top of existing modules to
"use v6.0.0.0" and punting on the default-defined-parameter question
until after Christmas. Changing "v6" to "v6.0.0.0" is a one-line
change to ease forward compatibility, and it eases the burden on
module authors. It's practical: Rakudo Star already accepts "use
v6.0.0.0;" without error. (In fact it even accepts "use v88;" which I
do not recommend in production :)


On Thu, Oct 15, 2015 at 12:48 AM, Richard Hainsworth
 wrote:
> Some suggestions:

Reading these brings MetaCPAN to mind:

>
> 1) On the perl 6 modules page (modules.perl6.org) , sort the modules by
> number of Badges, ...
> 2) Add another badge for 'reviewed'. ...
>
> 3) Would it be possible to develop a sort of Citation Index? That is the
> number of times a module uses another module? ...

MetaCPAN's "search" shows most of that info: how many people have
"favorited" it, how many reviews it has and the average "stars". Click
on a result, and it has "citations" linked to as "reverse
dependencies". Search page is not flexibly sortable in its default web
interface, but that is fixable. So... "all we need" are the tuits to
modify MetaCPAN to S22 and get it up on the web... sounds like fun,
not trivial though!

Or in other words, all good ideas that seem to have arose organically
in the P5 ecosystem. Let's adopt them back into P6 when we are
implementing the analogous tools/sites.

> 4) How about developing the 'bundle' idea more? Perhaps, putting Bundles on
> the Perl6 Modules top page, starting with Task::Star? Bundles could be
> moderated more strictly. Perhaps Bundle authors would need to supply a
> mandate, eg. "Bundle for GUI  development", or "Essential beginners bundle".
> Also bundle authors would need to have vetted the modules in the bundle,
> especially those without all badges.

Matches a comment about Perl 6 being like Linux, in how distributions
choose what to bundle with it. Rakudo Star has its choice of useful
modules bundled with it; other people's curatorial choices would be
interesting too...

Re: Backwards compatibility and release 1.0

[Richard Hainsworth]

Moritz rant away! Actually, I think this it is a very significant 
milestone in the development of a language and its ecosystem when 
backwards compatibility becomes an issue.


There will always be modules that have bit rot, insufficient 
documentation, inadequate testing, no reviews, etc. The problem is not 
their existence, but how they are perceived. Newcomers to Perl6 will not 
know much about which modules are useful, which are buggy, which are OK, 
etc. If a newcomer comes across some module that promises a lot and 
fails to work, it may not (unfortunately) be the module that gets the 
blame, but the Perl6 language/community/culture.


Some suggestions:

1) On the perl 6 modules page (modules.perl6.org) , sort the modules by 
number of Badges, with a label for each category like Good (all of the 
badges and 'build|passing'), Less Good (some badges and 
'build|passing'), Experimental (the rest). Perhaps also a warning about 
the modules in the category.
This way, the better quality modules are listed first by default. If 
someone wants to use a Less Good or Experimental module, they have been 
warned.


2) Add another badge for 'reviewed'. I found the CPAN reviews to be 
existentially useful, even if some of the content may be less useful. 
The fact that a module has been reviewed by someone other than the 
author increases my confidence that the module can be made to work. If 
there are negative comments, I am more cautious.


3) Would it be possible to develop a sort of Citation Index? That is the 
number of times a module uses another module? Citation Indices are 
widely used in academia to highlight key articles and papers. It's not 
an infallible tool as the system can be gamed, but it is much better 
than nothing.


4) How about developing the 'bundle' idea more? Perhaps, putting Bundles 
on the Perl6 Modules top page, starting with Task::Star? Bundles could 
be moderated more strictly. Perhaps Bundle authors would need to supply 
a mandate, eg. "Bundle for GUI  development", or "Essential beginners 
bundle". Also bundle authors would need to have vetted the modules in 
the bundle, especially those without all badges.


Regards,
Richard


On 10/14/2015 05:54 PM, Moritz Lenz wrote:

On 10/13/2015 10: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:



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.



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?


It is. But we still should try to limit the module author's burden.

In Practice, there's a small number of people who try to update 
modules to match when the compiler changed. Most module authors don't 
hang out in #perl6, eager to update their modules to the lastest 
rakudo change.


So a large percentage of the module updates are done by group of maybe 
five to a dozen volunteers. So, do the math: 5 people updating 70% of 
390 modules. Modules they are usually not all that familiar with, and 
usually don't have direct access. So they need to go through the pull 
request dance, waiting for reaction from the maintainer. In short, it 
sucks.


The ecosystem hasn't yet fully recovered from the s/done/done-testing/ 
change, nor from the GLR, nor from the need to prefix 'unit' to some 
declarations.


And this is why I'm getting increasingly frustrated and angry when 
people propose major breaking changes, brushing off the implications 
for the ecosystem and its maintainers with "but it's not 6.0", 
"shouldn't be a problem", "we aren't stable yet".


We want to release Perl 6 by Christmas, and it'll reflect *very* badly 
on us and the language if many modules in the ecosystem are broken. 
And any change that requires us to touch all .pm files will result in 
that.


Richard, I'm sorry that I'm writing the response in an email of yours; 
Mark or any number of p6l participants in the last few years triggered 
the same mental response from me. I only just now articulated it.




Cheers,
Moritz

Re: Exploit the versioning (was Re: Backwards compatibility and release 1.0)

[Darren Duncan]

On 2015-10-15 5:27 AM, yary wrote:

Short answer: everything must declare which semantics it expects-
everything in Panda/CPAN at least. And we already knew it, just need
to do it.


I believe this is something Perl 6 should require in general, if it doesn't. 
That is, it should be MANDATORY for Perl 6 code to declare what version of Perl 
it expects.  (The sole exception is one-liners.)  If we don't do this, people 
are going to be lazy and not say anything, and then there will be a large base 
of code that officially is just saying "any version of Perl 6 will do" but they 
silently actually expect Perl 6.0.0.0 semantics.  We're always going to be 
stuck with this problem if we don't make declarations mandatory now.  That's a 
much more important change to ingrain into those several hundred existing 
modules, if they aren't already, nevermind the :D thing. -- Darren Duncan

Re: Backwards compatibility and release 1.0

[Moritz Lenz]

On 10/13/2015 10: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:



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.



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?


It is. But we still should try to limit the module author's burden.

In Practice, there's a small number of people who try to update modules 
to match when the compiler changed. Most module authors don't hang out 
in #perl6, eager to update their modules to the lastest rakudo change.


So a large percentage of the module updates are done by group of maybe 
five to a dozen volunteers. So, do the math: 5 people updating 70% of 
390 modules. Modules they are usually not all that familiar with, and 
usually don't have direct access. So they need to go through the pull 
request dance, waiting for reaction from the maintainer. In short, it sucks.


The ecosystem hasn't yet fully recovered from the s/done/done-testing/ 
change, nor from the GLR, nor from the need to prefix 'unit' to some 
declarations.


And this is why I'm getting increasingly frustrated and angry when 
people propose major breaking changes, brushing off the implications for 
the ecosystem and its maintainers with "but it's not 6.0", "shouldn't be 
a problem", "we aren't stable yet".


We want to release Perl 6 by Christmas, and it'll reflect *very* badly 
on us and the language if many modules in the ecosystem are broken. And 
any change that requires us to touch all .pm files will result in that.


Richard, I'm sorry that I'm writing the response in an email of yours; 
Mark or any number of p6l participants in the last few years triggered 
the same mental response from me. I only just now articulated it.




Cheers,
Moritz

Re: Backwards compatibility and release 1.0

[Mark Overmeer]

* Moritz Lenz (mor...@faui2k3.org) [151014 09:54]:
> In Practice, there's a small number of people who try to update modules to
> match when the compiler changed. Most module authors don't hang out in
> #perl6, eager to update their modules to the lastest rakudo change.

With the relatively small number of P6 modules out there, and the enormous
impact on the number of bug-reports we will see once Perl6 is out, it may
be useful to pull everything "in", into a central archive where a number
of people can change everything.  Of course, it is not an ideal situation.
There are no ideal solutions.

Like it is done in the Linux kernel: once your driver gets accepted,
any change in core which affects the driver will be corrected by the one
who caused the change.  We need that ability for Perl6 syntax, I think.
-- 
Regards,

   MarkOv


   Mark Overmeer MScMARKOV Solutions
   m...@overmeer.net  soluti...@overmeer.net
http://Mark.Overmeer.net   http://solutions.overmeer.net

Exploit the versioning (was Re: Backwards compatibility and release 1.0)

[Darren Duncan]

I have a proposal.

Unlike with say the GLR, perhaps this whole :D thing may be a good test case for 
the Perl 6 feature of explicit language versioning.


How about we don't make the :D change now, and give more thought as to whether 
we actually want to do it at all.


If we do decide it is worthwhile, lets make it so that the :D change is part of 
Perl 6.1 say, along with any other changes we decide in the near future would be 
a good idea.


Then, programs that explicitly say "use 6.1" or such will get :D as default, 
while those that don't or say "use 6.0" etc will get the current behavior with 
:D not being default.


I say, save any further major breaking changes before this Christmas for things 
that would be really hard to change later and are sure to be worthwhile now, and 
the :D thing is not one of those.


What do you think?

-- Darren Duncan

On 2015-10-14 2:54 AM, Moritz Lenz wrote:

So a large percentage of the module updates are done by group of maybe five to a
dozen volunteers. So, do the math: 5 people updating 70% of 390 modules. Modules
they are usually not all that familiar with, and usually don't have direct
access. So they need to go through the pull request dance, waiting for reaction
from the maintainer. In short, it sucks.

The ecosystem hasn't yet fully recovered from the s/done/done-testing/ change,
nor from the GLR, nor from the need to prefix 'unit' to some declarations.

And this is why I'm getting increasingly frustrated and angry when people
propose major breaking changes, brushing off the implications for the ecosystem
and its maintainers with "but it's not 6.0", "shouldn't be a problem", "we
aren't stable yet".

We want to release Perl 6 by Christmas, and it'll reflect *very* badly on us and
the language if many modules in the ecosystem are broken. And any change that
requires us to touch all .pm files will result in that.

Re: Exploit the versioning (was Re: Backwards compatibility and release 1.0)

[Darren Duncan]

On 2015-10-14 6:14 AM, Parrot Raiser wrote:

Is this particular change one that could be implemented
algorithmically, or at least partially so?
(E.g. For all modules
  check for the presence of a ":D".
  If it's there, no action.
  If not, insert a line of code. Run a test.
  If successful, post change.
  If not, alert a human)


I think this can be done, yes, and in principle it would be a good idea.

But the problem Moritz seemed to be raising is that each of the Perl 6 modules 
is possibly in different repositories under a wide variety of users, and it 
would still count on a lot of people to take action to accept those changes in 
order to not have a lot of breaking.


While I agree that changing the modules would be better quality-wise, my 
versioning proposal is likely more practical if we're trying to focus on 
stability now for a Christmas release.


I mean, this situation seemed to be a solid example of why Perl 6's versioning 
scheme exists in the first place, to deal elegantly with things like this.


-- Darren Duncan

Re: Exploit the versioning (was Re: Backwards compatibility and release 1.0)

[Parrot Raiser]

Is this particular change one that could be implemented
algorithmically, or at least partially so?
(E.g. For all modules
 check for the presence of a ":D".
 If it's there, no action.
 If not, insert a line of code. Run a test.
 If successful, post change.
 If not, alert a human)

Re: Backwards compatibility and release 1.0

[Darren Duncan]

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:



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.



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.