Re: Dallas.p6m

2009-03-20 Thread Andy Lester


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

2009-03-20 Thread Timothy S. Nelson

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

2009-03-20 Thread Daniel Ruoso
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

2009-03-20 Thread Jonathan Worthington

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

2009-03-20 Thread Daniel Ruoso
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

2009-03-20 Thread Jonathan Worthington

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)

2009-03-20 Thread Patrick R. Michaud
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

2009-03-20 Thread Darren Duncan

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