1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
|
=encoding utf-8
=head1 NAME
Guide to the C<src/setting/> library
=head1 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.
=head2 Reasons
There are a few reasons to write built-in methods in Perl 6 and not in
PIR, as done previously:
=over
=item Perl 6 is a much nicer language than PIR
=item Typed Arrays/Lists are really parametric roles, and those are
much easier to write in Perl 6
=item 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.
=back
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.
=head2 Guidelines
Your patches to migrate PIR builtins to Perl 6 are very welcome,
especially if they follow these guidelines:
=over
=item 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 C<for> loop, which will respect laziness
for self.list { ... }
If you assemble multiple items into a potentially lazy list,
C<gather/take> is a very good construct to remember.
=item 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.
=item When adding a new file in src/setting/
... remember to add it to L<build/Makefile.in> to the C<SETTING>
variable and re-generate the Makefile using L<Configure.pl>.
=item Prefer C<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 C<@values>
will restrict the method to invocants that have the C<Positional>
role). Better is to use C<self>, or if invoking a method on C<self>
then you can use C<$.foo> or C<@.bar> directly.
=item All subs and methods are really multis
All built-in methods or subroutines should be declared as C<multi>.
=item Use explicit empty signatures
If a method doesn't take any arguments, give it an explicit empty
signature C<()>. That's very different from omitting the signature
altogether (which would be an implicit catch-all signature).
=item Use implicit return at the end of routines
If no C<return> statement is executed in a routine, the value of the
last evaluated expression is returned.
So if a C<return EXPR> is the last statement in a routine, omit the
C<return> - currently explicit returns take much more time
than implicit ones.
=back
=head1 SEE ALSO
L<http://rakudo.org/2009/02/rakudo-built-ins-can-now-be-wr.html>
L<http://perlgeek.de/blog-en/perl-6/tidings-2009-03.html>
=for editor vim: ft=pod tw=70
|
