Moritz Lenz wrote [on perl6-language]:
On Tue, Sep 15, 2009 at 09:30:13AM +0530, Saravanan Thiyagarajan wrote:
Would like to be a volunteer in working for perl-6.
Can some one help me to get into right direction ?

I've written about various options on perlmonks [1], but I think the best
thing you can do right now is to pick a simple Perl 5 module, and port it to
Perl 6. If you find any bugs along the way, join us in #perl6 on and tell us about your bug. If you are sure that it's really
a bug, send a mail to

I have a medium-sized Perl 5 module, Set::Relation ( ) that I'd be very happy if it were translated to Perl 6, but I currently lack the tuits as I'm focusing on other related projects at the moment.

So if someone else wants to do that as a way to help the Perl 6 effort, they have my blessing and support.

I believe that having a native relation type in Perl 6 would be valuable because there is so much of practical value you can do with them, and Set::Relation was created largely as a working proof of concept towards this end.

Set::Relation was designed from day one to be translated to Perl 6, but I made it in Perl 5 + Moose first because that was a more stable platform, and I wanted to actually /use/ it in Perl 5 programs meanwhile.

Set::Relation models the same relation values that relational databases are composed from, and includes probably all of the relational operators you've ever heard of plus some. Loosely speaking, a Set::Relation object is like a "Set of Mapping" (or "Array of Hash" where all Array elements are distinct), but that there is such a thing as the Set/Array having zero elements (tuples) but it still has a known identity described by 0..N Mapping/Hash keys (r/t attribute names). Traditionally the keys/attrs have been character strings but the model still works if they are any (ideally scalar) type; the point is that relation attributes are addressed by name rather than by position, but what constitutes a name can be flexible.

Currently defined are 2 roles + 2 classes; the main role defines an immutable object and the second role extends it to add mutability; the V1 class does the mutable superset while the V2 class does only the immutable subset. I strongly recommend that a porter initially just tries the immutable role and V2, and ignores V1 and the mutable role for now, as it is a lot easier to implement this thing when you don't have to worry about deep copying.

The current Set::Relation is licensed LGPLv3+ but I am willing to relicense it to Artistic v2+ if that assists a porting effort.

-- Darren Duncan

Reply via email to