[perl6/specs] 3ac3d1: tyop
Branch: refs/heads/master Home: https://github.com/perl6/specs Commit: 3ac3d18ecf4e9205b4457fc1f9a13106bde1bceb https://github.com/perl6/specs/commit/3ac3d18ecf4e9205b4457fc1f9a13106bde1bceb Author: Stéphane Payrard Date: 2015-10-13 (Tue, 13 Oct 2015) Changed paths: M S04-control.pod Log Message: --- tyop
[perl6/specs] 8fb3cd: various minor casing/spacing/grammar/syntax fixes
Branch: refs/heads/master Home: https://github.com/perl6/specs Commit: 8fb3cd9b332c69e88ffc00b8be0a105c98142313 https://github.com/perl6/specs/commit/8fb3cd9b332c69e88ffc00b8be0a105c98142313 Author: Nova Patch Date: 2015-10-13 (Tue, 13 Oct 2015) Changed paths: M S02-bits.pod M S03-operators.pod M S05-regex.pod M S06-routines.pod M S15-unicode.pod M S17-concurrency.pod M S19-commandline.pod M S22-package-format.pod M S28-special-names.pod M S29-functions.pod M S32-setting-library/IO.pod M S99-glossary.pod M html/index.html Log Message: --- various minor casing/spacing/grammar/syntax fixes ◦ unicode→ Unicode [except unicode pragma] ◦ Perl6 → Perl 6 ◦ Perl5 → Perl 5 [except Perl5ish] ◦ a → an [before vowel sounds] ◦ c<…> → C<…> ◦ $*ARGS → @*ARGS ◦ :p5→ :P5 ◦ Unicode database → Unicode Character Database [http://unicode.org/glossary/#unicode_character_database] ◦ unicode normalisation form → Unicode normalization form [http://unicode.org/glossary/#normalization_form] also minor punctuation changes on some of the lines modified
Re: Backwards compatibility and release 1.0
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
* 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)
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: To :D or not to :D
Hi Patrick, thank you for your thoughts. I needed a bit more time for the response ;-) * Patrick R. Michaud (pmich...@pobox.com) [151013 01:05]: > On Tue, Oct 13, 2015 at 12:32:01AM +0200, Mark Overmeer wrote: > > Yes, that what I started realizing when I saw all the pain Perl6 goes to > > ignore the existence of a real "undef" in the language. (I follow Perl6 > > from a short distance since its start, read all original designs, but > > this penny did not drop before, sorry) > > Actually, it's the other way around. Perl 6 is not trying to ignore > the existence of an "undef", it's recognizing that there are in fact > many different kinds of undef. It's the languages that think there's > only one "real undef" that are confused. :) Yes, I like the typed undef... as real undef. Let's call it "Car:undef" when it fits in a Car typed variable which is not used yet. Easy to understand for Perl5 people. > > my Car $a; my Car $b; Now I have two different types. > > Not really, you have two variables, both of which have been > initialized to the same (undefined) Car object. It's not > much different than > >my Int $a; my Int $b; $a = $b = 1; > > where $a and $b end up being variables that contain the same > Int object. This is a different view on the syntax layer: implementor vs programmer. As programmer, knowing of optimizations of this kind adds to the confusion, not to the understanding. As long as my Int $a; my Int $b; $a = $b = 1; $b = 2; $a.say, $b.say produces 1\n2\n, I'm fine with any implementation. I don't want to know how it is done internally. > I think Self would be the (pardon the pun) prototypical example, and > it's also a common feature of JavaScript. As to whether there is > precedence in other "successful" programming languages I use it in JavaScript. I reread a few tutorials about OO/prototype in Javascript yesterday. They smoothly speak about adding methods to objects etc. They speak about types and objects in a very natural way. They don't speak about undef objects to contain types, which are used as object factory. I have not found the need for :U there. > Perl 6 still has classes and instances, but Perl 6 also adds the > ability to represent undefined instances of a type (or, rephrased, > to have typed "undefs"). Perl 6 then binds the commonly-used > identifier (e.g., C) to an undefined instance rather than the > class object that defines the instances. Once you accept that model, > it seems to work out very well in practice. Trying to reformulate this without spoilers of internal details: Perl6 has classes, instances, and prototypes. Commonly used types, like Int, are prototypes based on classes. Therefore, they can easily absorb features via Roles and Mixins. Note about the internals: we are not keeping a separate administration of type features, but keep that inside the instantiated objects. As all prototype-based languages do. Acceptable? > If Research refers instead to the class definition, then the > method namespaces for instances and classes begin to clash, and > we have to introduce all sorts of disambiguation for that. Yes, disambiguation either via a keyword (class method/instance method) or via the invocant (being a type :T or instance... multi methods to the rescue) For me, prototypes in JavaScript work well, because all graphical elements on the screen are slightly different in behavior. I am a bit afraid to get into swamps when programs are large, where it is already hard to keep track on all the cleanly organized classes. So... my hessitation seems to be limited to the explanation and name of the flag :U, which tell me that a type is an undef. Type defining features are loaded into a base object which does not carry a value: yes. Via specialization you get objects which carry a value. Maybe this comes back to the distiction between implicit and explicit undefinedness. -- MarkOv Mark Overmeer MScMARKOV Solutions m...@overmeer.net soluti...@overmeer.net http://Mark.Overmeer.net http://solutions.overmeer.net
Re: To :D or not to :D
> * Patrick R. Michaud (pmich...@pobox.com) [151013 01:05]: >> On Tue, Oct 13, 2015 at 12:32:01AM +0200, Mark Overmeer wrote: >>> Yes, that what I started realizing when I saw all the pain Perl6 goes to >>> ignore the existence of a real "undef" in the language. (I follow Perl6 >>> from a short distance since its start, read all original designs, but >>> this penny did not drop before, sorry) >> Actually, it's the other way around. Perl 6 is not trying to ignore >> the existence of an "undef", it's recognizing that there are in fact >> many different kinds of undef. It's the languages that think there's >> only one "real undef" that are confused. :) > Yes, I like the typed undef... as real undef. Let's call it "Car:undef" > when it fits in a Car typed variable which is not used yet. Easy to > understand for Perl5 people. Why do we need to add an adverb on a type to talk about the type? If you want to pass a class around for example, do you alsway want to but an ":undef" on it? Then somebody would ask: "What do I get when I dont put said :undef on it?" - And the answer might be "Well, you get basically the same." Also please keep in mind that Perl 6 does not have to be seen from a Perl 5 perspective. There are more valid views. >>> my Car $a; my Car $b; Now I have two different types. >> Not really, you have two variables, both of which have been >> initialized to the same (undefined) Car object. It's not >> much different than >> >>my Int $a; my Int $b; $a = $b = 1; >> >> where $a and $b end up being variables that contain the same >> Int object. > This is a different view on the syntax layer: implementor vs programmer. > As programmer, knowing of optimizations of this kind adds to the > confusion, not to the understanding. As long as >my Int $a; my Int $b; $a = $b = 1; $b = 2; $a.say, $b.say > produces 1\n2\n, I'm fine with any implementation. I don't want to know > how it is done internally. No, rot really. You stated that you have two dirrenent types there, but it really is the very same type. It is just so that two variables containing it. >> I think Self would be the (pardon the pun) prototypical example, and >> it's also a common feature of JavaScript. As to whether there is >> precedence in other "successful" programming languages > I use it in JavaScript. I reread a few tutorials about OO/prototype > in Javascript yesterday. They smoothly speak about adding methods to > objects etc. They speak about types and objects in a very natural way. > They don't speak about undef objects to contain types, which are used > as object factory. I have not found the need for :U there. I've also not used :U in Perl 6 yet. There might be scenarios where you want to accept, say, class definitions only but these cases are rare I'd say. More often you call a construction on a type, or smartmatch a value agains a type. And this really happens regularly in idomatic Perl 6 code. >> Perl 6 still has classes and instances, but Perl 6 also adds the >> ability to represent undefined instances of a type (or, rephrased, >> to have typed "undefs"). Perl 6 then binds the commonly-used >> identifier (e.g., C) to an undefined instance rather than the >> class object that defines the instances. Once you accept that model, >> it seems to work out very well in practice. > Trying to reformulate this without spoilers of internal details: > > Perl6 has classes, instances, and prototypes. Commonly used > types, like Int, are prototypes based on classes. Therefore, > they can easily absorb features via Roles and Mixins. > > Note about the internals: we are not keeping a separate > administration of type features, but keep that inside the > instantiated objects. As all prototype-based languages do. > > Acceptable? > >> If Research refers instead to the class definition, then the >> method namespaces for instances and classes begin to clash, and >> we have to introduce all sorts of disambiguation for that. > Yes, disambiguation either via a keyword (class method/instance method) > or via the invocant (being a type :T or instance... multi methods to > the rescue) > > For me, prototypes in JavaScript work well, because all graphical > elements on the screen are slightly different in behavior. I am a bit > afraid to get into swamps when programs are large, where it is already > hard to keep track on all the cleanly organized classes. > > So... my hessitation seems to be limited to the explanation and name > of the flag :U, which tell me that a type is an undef. Type defining > features are loaded into a base object which does not carry a value: yes. > Via specialization you get objects which carry a value. > > Maybe this comes back to the distiction between implicit and explicit > undefinedness.
Re: Exploit the versioning (was Re: Backwards compatibility and release 1.0)
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: Exploit the versioning (was Re: Backwards compatibility and release 1.0)
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
