NAME

Guide to the src/setting/ library

DESCRIPTION

Why we write built-in methods and functions in Perl 6, and what you should know when you write more such subs or methods.

Reasons

There are a few reasons to write built-in methods in Perl 6 and not in PIR, as done previously:

Perl 6 is a much nicer language than PIR

Typed Arrays/Lists are really parametric roles, and those are much easier to write in Perl 6

In order for Rakudo's multi-dispatchers to work properly, the target subs have to have Signature objects attached to them. This is far easier to do in Perl 6 than in PIR.

There are two potential drawbacks: (1) slower execution, and (2) some operations can be expressed in PIR that cannot yet be expressed in Rakudo (and sometimes not even in Perl 6!). For cases where these drawbacks matter, we can use inline PIR or maintain the subroutines in PIR as needed.

Guidelines

Your patches to migrate PIR builtins to Perl 6 are very welcome, especially if they follow these guidelines:

Think of laziness

At some point in the hopefully not-so-distant future Lists will become lazy by default. So you should try to avoid anything that forces eager evaluation of arrays, like querying their length.

This is bad:

    while $i < self.elems { ... }

Better use a for loop, which will respect laziness

    for self.list { ...  }

If you assemble multiple items into a potentially lazy list, gather/take is a very good construct to remember.

Take care with type constraints

Some of the Synopsis documents list type constraints for some of the arguments, including the invocant. They are not always correct, when in doubt leave them out.

When adding a new file in src/setting/

... remember to add it to "Makefile.in" in build to the SETTING variable and re-generate the Makefile using Configure.pl.

Prefer self to explicit invocant variables.

Many of the method specifications in the synopses list explicit invocant variables. Using them often makes the code less clear, and can sometimes be incorrect (for example, an invocant of @values will restrict the method to invocants that have the Positional role). Better is to use self, or if invoking a method on self then you can use $.foo or @.bar directly.

All subs and methods are really multis

All built-in methods or subroutines should be declared as multi.

Use explicit empty signatures

If a method doesn't take any arguments, give it an explicit empty signature (). That's very different from omitting the signature altogether (which would be an implicit catch-all signature).

Use implicit return at the end of routines

If no return statement is executed in a routine, the value of the last evaluated expression is returned.

So if a return EXPR is the last statement in a routine, omit the return - currently explicit returns take much more time than implicit ones.

SEE ALSO

http://rakudo.org/2009/02/rakudo-built-ins-can-now-be-wr.html

http://perlgeek.de/blog-en/perl-6/tidings-2009-03.html