This week on Perl 6, week ending 2003-04-20
by Piers Cawley
|
Pages: 1, 2, 3
Perl 6 parser questions
Right at the end of last week, Austin Hastings asked a bunch of questions about the behaviour of the Perl 6 parser. He wondered, for instance, if, in the future, he'd be able to (usefully) say:
#!/usr/bin/perl6.1
use Perl6::Grammar v6.0.0.2;Larry answered this question ("I don't see why not") and all of Austin's other questions on this topic. Apparently the Perl 6 Parser will be documented 'whenever Apocalypse 18 comes out'.
http://groups.google.com/groups
Initializations outside of control flow
Mark J.
Reed asked about elegant ways of initializing shared variables.
He wanted something a little neater than the blunderbuss of a BEGIN block.
Larry obliged with one of his 'thinking aloud' posts which,
while not giving us a final answer does give us a few signposts.
It's looking like we'll have traits along the lines of:
state $where is begin($value);
state $where is check($value);
state $where is init($value);
state $where is first($value);Where the traits work analogously to BEGIN,
CHECK,
INIT and FIRST.
http://groups.google.com/groups
http://groups.google.com/groups
The new returns keyword
David Storrs was a little worried about the possible clash between the new returns keyword -- introduced in Apocalypse 6 -- and return.
Michael Lazzaro pointed out that the 'possible clash' was almost certainly deliberate,
after all:
sub foo returns Bar {...}reads rather well.
David had used the example my $spot returns Dog,
which does look rather ugly,
but Michael pointed out,
in the case of a variable declaration,
it made more sense to use my $spot of Dog or even my Dog $spot.
Michael commented that this choice of syntax meant the programmer was able to pick the most readable phrase for a given situation.
http://groups.google.com/groups
A17 early discussion: Perl 6 threading proposal
Austin Hastings posted what would once have been called an RFC about Perl 6's threading model. No comments so far.
http://groups.google.com/groups
wrap from Synopsis 6
David Storrs wondered if the new .wrap method,
which returns a unique id identifying the particular 'wrapper' could have an associated warning if the resulting id wasn't stored somewhere.
Adam D.
Lopresto and Austin Hastings weren't keen...
http://groups.google.com/groups
The difference between - $arg {...}> and sub ($arg) {...}
David Storrs asked for a 'micro-Exegesis' on the difference between - $foo {...}> and sub ($foo) {...} since they both seemed to generate anonymous subroutines.
There were an awful lot of responses to this.
Essentially the difference is that a 'pointy block' (my coinage I think) is just a block that has a signature.
The main difference is what happens to a return.
In a block or a pointy block,
a return returns from the subroutine that lexically contains that block,
not simply from the block itself.
If you want to leave a block prematurely without returning from its enclosing subroutine,
you would use the leave keyword.
This distinction between a Block and a Sub allows for some rather neat (Smalltalkish) idioms
multi iterate_over_file( String $path: Block &block ) {
my $fh = open File: '<', $path or
fail "Couldn't open $path: $!";
while <$fh> {
&block($_);
}
}
sub find_user ($user_name) {
iterate_over_file "/etc/passwd" -> $line {
return $line but true if /^$user_name/;
}
return undef;
}This is a somewhat contrived example,
but I think it's useful as an illustration.
If a Block were exactly the same as a sub,
then the return in find_user would return to the middle of the while loop in iterate_over_file and iterate_over_file would only return after it had gone through every line in the password file,
which would mean that find_user would always return undef.
However,
a return from inside a block returns from the subroutine containing the block so find_user behaves as expected and we get to write powerful control structures without having to resort to macros.
I do wonder if the it would be possible for a function like iterate_over_file to CATCH the block's Return exception though...
http://groups.google.com/groups
Compulsorily named parameters?
The debate over declaring non optional named parameters continued as Damian joining in. The current consensus appears to be that the various optional/named/slurpy shorthands introduced in Apocalypse 6 should stay pretty much as they are, but that it should be possible to declare more complex parameter requirements using sensibly named traits. John Siracusa still wants a more 'powerful' shorthand, but there doesn't seem to be anyone taking his side on that.
http://groups.google.com/groups
Multimethod invocants
Multimethods still appear to be causing some confusion, mostly to do with how they are called and dispatched, and which method parameters participate in the dispatch. There's a largish contingent (and I probably my count myself a member of that contingent, spot the bias) who would like to be able to write:
multi infix:@ (Number $x, Number $y) { new Point: $x, $y }
class point {
...
multi make_rectangle ( Point $p ) {
new Rectangle: $_, $p;
}
multi make_rectangle ( Number $x, Number $y ) {
.make_rectangle( $x @ $y );
}
}Which isn't allowed. Instead you would have to write:
multi make_rectangle ( Point $p, Point $q ) {
new Rectangle: $p, $q;
}
multi make_rectangle ( Point $p, Number $x, Number $y ) {
make_rectangle ($p, $x @ $y);
}And you also have to be wary of
my Point $p;
...
$p.make_rectangle($x @ $y);which would first try to dispatch to Point's make_rectangle 'unimethod',
only attempting to dispatch via a multimethod if there is no such method.
Personally,
I think there's room for a spoonful or two of syntactic sugar to allow for the 'method variant' style of declaration as well as the full on generic multimethod style (which would,
of course,
underpin the more restricted method variant style).
However,
if it doesn't exist out of the box I expect someone (me?) will write a set of macros to make things work.
In the message referenced, Damian explains the current state of the multimethod art...
http://groups.google.com/groups
