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
irc.freenode.net and tell us about your bug. If you are sure that it's really
a bug, send a mail to rakudo...@perl.org.
I have a medium-sized Perl 5 module, Set::Relation (
http://search.cpan.org/dist/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
