Re: Dallas.p6m
On Mar 18, 2009, at 5:26 PM, fREW Schmidt wrote: s1n and I decided that we would start Dallas.p6m as we are close to each other geographically speaking. We are meeting tomorrow (Thursday, March 19, 7:00PM) at a coffee shop with free wifi. The address is 985 W Bethany Dr Allen, TX 75013. This is more to the world of Perl 6, but you're the first person to go out there and do this. I love love LOVE starting to get people together to talk about Perl 6. It's a crucial step in letting people know that Perl 6 is real. However, starting social groups that say they are specifically about Perl 6 makes me uncomfortable. I think it would be better to call it Dallas.pm and just talk about Perl 6 in the meeting announcements. The key is that we don't want people to think they must choose one or the other. Technologically, Perl 5 and Perl 6 are very different, but culturally, they're very similar. Keeping Perl 5 and Perl 6 groups together also means that we will increase cross-pollination of Perl 6 onto the Perl 5 people. Thanks for listening, xoxo, Andy -- Andy Lester = a...@petdance.com = www.petdance.com = AIM:petdance
Re: Dallas.p6m
On Thu, 19 Mar 2009, Andy Lester wrote: I think it would be better to call it Dallas.pm and just talk about Perl 6 in the meeting announcements. The key is that we don't want people to think they must choose one or the other. Technologically, Perl 5 and Perl 6 are very different, but culturally, they're very similar. Keeping Perl 5 and Perl 6 groups together also means that we will increase cross-pollination of Perl 6 onto the Perl 5 people. While I don't deny the truth of what you're saying, it seems to me that languages get a buzz with the newness factor; people are interested in them for no reason other than that they're new. It seemed this way to me with Python and Ruby, and probably Java too. I'm wondering if we can't get the newness factor by branding Perl 6 slightly differently, while at the same time carrying the existing Perl community across the 5/6 boundary. In other words, I think the situation should be a both/and, not an either/or. :) - | Name: Tim Nelson | Because the Creator is,| | E-mail: wayl...@wayland.id.au| I am | - BEGIN GEEK CODE BLOCK Version 3.12 GCS d+++ s+: a- C++$ U+++$ P+++$ L+++ E- W+ N+ w--- V- PE(+) Y+++ PGP-+++ R(+) !tv b++ DI D G+ e++ h! y- -END GEEK CODE BLOCK-
Re: r25891 - in docs/Perl6/Spec: . S32-setting-library
Em Qua, 2009-03-18 às 18:50 -0700, Larry Wall escreveu: On Wed, Mar 18, 2009 at 06:32:18PM -0700, Jon Lang wrote: : +method !eigenstates (Junction $j: -- List) : : Shouldn't that be lowercase-j junction? Maybe, though there might be a Junction role involved for subtype matches like that one. Actually, if we support that, we kinda loose the point of making it a native type... daniel
Re: r25891 - in docs/Perl6/Spec: . S32-setting-library
Daniel Ruoso wrote: Em Qua, 2009-03-18 às 18:50 -0700, Larry Wall escreveu: On Wed, Mar 18, 2009 at 06:32:18PM -0700, Jon Lang wrote: : +method !eigenstates (Junction $j: -- List) : : Shouldn't that be lowercase-j junction? Maybe, though there might be a Junction role involved for subtype matches like that one. It's probably a minor issue, but part of me wants Junction to be OK too for explaining stuff. Telling people the default parameter type is Any, to accept anything they can write Object and to accept just junctions you write Junction is pretty clear...having to then explain why you write Any and Object but then junction (lowercase) feels awkward. Actually, if we support that, we kinda loose the point of making it a native type... I don't quite follow this. But it does bring an interesting point - if we have a Junction role then it's probably something that people can do on their own classes to make their own thingies that auto-threading. It had perhaps better require things doing the role to provide the !eigenstates private though, otherwise the dispatcher is going to be rather unhappy... Jonathan
Re: r25891 - in docs/Perl6/Spec: . S32-setting-library
Em Sex, 2009-03-20 às 14:08 +0100, Jonathan Worthington escreveu: It's probably a minor issue, but part of me wants Junction to be OK too for explaining stuff. Telling people the default parameter type is Any, to accept anything they can write Object and to accept just junctions you write Junction is pretty clear...having to then explain why you write Any and Object but then junction (lowercase) feels awkward. everything is an Object. not everything is Any. That is still true. junction is a native type that doesn't do Any, and so far it seems to be the only one. The capital vs lowercase J does not change that, it only tells you that you cannot subclass junction as you can with non-native objects. Actually, if we support that, we kinda loose the point of making it a native type... I don't quite follow this. The point of having it as native is that you don't need to do a high-level method call to implement the autothreading, since it's a native type, you can assume its representation format and go directly into its guts to get the values... But it does bring an interesting point - if we have a Junction role then it's probably something that people can do on their own classes to make their own thingies that auto-threading. Meaning the auto-threading need to do a high-level method call to do that... It had perhaps better require things doing the role to provide the ! eigenstates private though, otherwise the dispatcher is going to be rather unhappy... But... if the dispatcher needs to call it, it shouldn't be private right? or is the dispatcher a specific class that Junction implementation can trust? daniel
Re: r25891 - in docs/Perl6/Spec: . S32-setting-library
Daniel Ruoso wrote: Em Sex, 2009-03-20 às 14:08 +0100, Jonathan Worthington escreveu: It's probably a minor issue, but part of me wants Junction to be OK too for explaining stuff. Telling people the default parameter type is Any, to accept anything they can write Object and to accept just junctions you write Junction is pretty clear...having to then explain why you write Any and Object but then junction (lowercase) feels awkward. everything is an Object. not everything is Any. That is still true. junction is a native type that doesn't do Any, and so far it seems to be the only one. The capital vs lowercase J does not change that, it only tells you that you cannot subclass junction as you can with non-native objects. I know all of this, I was more arguing for those who don't who need to learn it. :-) Actually, if we support that, we kinda loose the point of making it a native type... I don't quite follow this. The point of having it as native is that you don't need to do a high-level method call to implement the autothreading, since it's a native type, you can assume its representation format and go directly into its guts to get the values... Given method calls are so common in Perl 6 and something we probably want to make pretty fast anyway, I don't know there's a serious performance argument here. But it does bring an interesting point - if we have a Junction role then it's probably something that people can do on their own classes to make their own thingies that auto-threading. Meaning the auto-threading need to do a high-level method call to do that... It had perhaps better require things doing the role to provide the ! eigenstates private though, otherwise the dispatcher is going to be rather unhappy... But... if the dispatcher needs to call it, it shouldn't be private right? or is the dispatcher a specific class that Junction implementation can trust? Well, we've gone from eigenstates being added to Object on one day to needing to remove it from that and make it private in junction a few days later, so I'm still feeling quite wait and see on whether it really will end up private. :-) I guess the dispatcher can be trusted, or actually just defined inside the junction class anyway... Jonathan
Rakudo Perl development release #15 (Oslo)
On behalf of the Rakudo development team, I'm pleased to announce the March 2009 development release of Rakudo Perl #15 Oslo. Rakudo is an implementation of Perl 6 on the Parrot Virtual Machine [1]. The tarball for the March 2009 release is available from http://www.pmichaud.com/perl6/rakudo-2009-03.tar.gz However, because of the rapid pace of Rakudo development and addition of new features, we still recommend that people wanting to use or work with Rakudo obtain the latest version directly from the main repository at github -- more on this in a bit. Rakudo Perl follows a monthly release cycle, with each release code named after a Perl Mongers group. This release is named Oslo in honor of the organizers of the 2009 Nordic Perl Workshop [2], April 16-17, 2009. The 2009 Nordic Perl Workshop will have a special focus on Perl 6, Rakudo Perl, and Parrot, including Perl 6 tutorials and hackathons after the conference itself. A list of the other planned release dates and codenames for 2009 is available in the docs/release_guide.pod file. In general, Rakudo development releases are scheduled to occur two days after each Parrot monthly release. Parrot releases the third Tuesday of each month. Rakudo Perl now uses git [3] for its version control system, hosted at http://github.com/rakudo/rakudo . The README file there is kept up-to-date with the latest instructions for obtaining and building Rakudo Perl. In this release of Rakudo Perl, we've made the following major changes and improvements: * Rakudo is now passing 7273 spectests. This is an increase of 197 passing tests since the February 2009 release. * The eval() construct now understands lexical variables from an outer scope. * More of the builtin functions (settings) are being written in Perl 6. * Rakudo supports the R (reverse) metaoperator. * Parsing of if, unless, while, until, etc. statements after blocks now works correctly. * The Q quote operator is now implemented, along with several adverbial forms. In particular, the Q:PIR form allows inline PIR to be included in Perl 6 code. * Multi-method dispatch now works with inheritance also. The development team thanks all of our contributors and sponsors for making Rakudo Perl possible. The next release of Rakudo (#16) is scheduled for April 23, 2009. References: [1] Parrot, http://parrot.org/ [2] Nordic Perl Workshop 2009, http://www.perlworkshop.no/npw2009/ [3] Git version control system, http://git-scm.org/
Re: routine arrow syntax and return/of types
Jon Lang wrote: And AFAIK the token -- is used in exactly one place in perl 6: within signature syntax, to mark the transition from the parameter signature to the return type signature. As with Darren, I don't see why this would be a big problem. The biggest stumbling block that I can think of is that a return type cannot have an invocant, whereas the parameter signature might be able to have one. May I inquire as to the nature of the complications that I'm missing, for my own edification? (If you can't afford the time, I'll understand.) Unless there is some rule that an invocant has to be at the start of the parenthetical routine signature list, I don't see a problem. So we just have for example: sub myfunc (Int -- Int $self: Int $other) {...} In fact I would expect any invocant to be after the -- since it is really just a parameter. Spitballing here: you drew an analogy to the feed operators. I wonder if that analogy could be taken further: use -- and -- outside of signatures as feed operators - but instead of feeding arrays back and forth, have them feed capture objects and engage in some implicit currying. That is: foo -- $capture $capture -- foo would both be equivalent to: foo :assuming(|$capture) ...or something to that effect. So instead of composing a series of functions by nesting them in each others' argument lists, you could do so by chaining them together using -- or --. That could be interesting. But do you have an example use case or example code illustrating its use? As for the idea I raised to support --, I have gone ahead anyway and designed it into my cross-breed of Perl 6 and SQL called Muldis D (as of v0.62.2), as the way of declaring a routine, rather than one of 4 ways. See the following url for a bunch of example routine signatures demonstrating it: http://search.cpan.org/dist/Muldis-D/lib/Muldis/D/Core/Routines.pod At the same time I revamped my routine declaration format in other ways, and as you can see this aspect of Muldis D now looks so much like Perl 6 they might be indistinguishable at a glance, or regardless I think it can serve as reasonable examples of how Perl 6 itself could look. -- Darren Duncan