Skip to content
This repository

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
branch: extend-dump
Fetching contributors…

Cannot retrieve contributors at this time

file 107 lines (67 sloc) 3.224 kb

Guide to the src/setting/ library

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

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

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.

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

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.

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.

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

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 built-in methods or subroutines should be declared as multi.

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).

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.

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

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

Something went wrong with that request. Please try again.