Implicit current-index variable, scoped inside for-loops
Yobert Hey do you know what would be cool in perl 6
Yobert A special variable for when you do a for (@array) style loop
Yobert it would always have the index of the array
Discussed on #perl6: it's already quite easy in Perl 6 to loop with an
explicit index:
my @array = moose elk caribou;
for @array.kv - $i, $val {
say $i\t$val;
}
But maybe a variable that implicitly carries along the loop index
would be even snazzier?
for @array - $val {
say $.\t$val;
}
(Change $. to whatever name would actually be appropriate in this
case. $. contains the current line number for the last filehandle
accessed in Perl 5, and that's probably why I came to think of it
here.)
Questions:
- Is the itch big enough for this? The more I look at the first piece
of code, the more I'm thinking that's not so bad, really. (Though
opinions differed on the IRC channel.) Is there a situation I'm not
thinking of where the first piece of code would suck, and the second
piece of code would rock? Or is this a case of oversugaring?
- I feel there's a trend of moving away from line-noise variables. I'd
hate to be one to propose adding a new one to the language. Is there a
better syntax than $.?
- How would this work with non-array data? Specifically, what happens
with next, redo etc on a filehandle, for example?
See
http://colabti.de/irclogger/irclogger_log/perl6?date=2006-08-29,Tuesel=145#l205
for the #perl6 discussion.
--
masak
Re: Implicit current-index variable, scoped inside for-loops
Carl Mäsak wrote:
But maybe a variable that implicitly carries along the loop index
would be even snazzier?
for @array - $val {
say $.\t$val;
}
Or give the block a name (label), and have an index (or several indexes, like
some that are reset by redo an some that are not) available, attached to that
name.
--
Affijn, Ruud
Re: Implicit current-index variable, scoped inside for-loops
Ruud (), Carl ():
But maybe a variable that implicitly carries along the loop index
would be even snazzier?
for @array - $val {
say $.\t$val;
}
Or give the block a name (label), and have an index (or several indexes, like
some that are reset by redo an some that are not) available, attached to that
name.
That sounds like an interesting idea. Do you have a short snippet to
hint of what that would look like?
--
masak
Re: Implicit current-index variable, scoped inside for-loops
Carl Mäsak wrote:
Yobert Hey do you know what would be cool in perl 6
Yobert A special variable for when you do a for (@array) style loop
Yobert it would always have the index of the array
Discussed on #perl6: it's already quite easy in Perl 6 to loop with an
explicit index:
my @array = moose elk caribou;
for @array.kv - $i, $val {
say $i\t$val;
}
But maybe a variable that implicitly carries along the loop index
would be even snazzier?
Whatever is done should also work for grep and map.
--
[EMAIL PROTECTED]
[EMAIL PROTECTED]
Classes / roles as sets / subsets
Originally this posting was written in response to the 'ref' spec
thread. I included char diagrams that got screwed up, so I made a png
diagram instead (attached) and I re-edited the posting to refer to
attached diagram, and then added some more comments. Hope everyone can
'see' the png.
I find classes and roles, and multiple inheritance in general, difficult
to understand. Larry Wall talked about subsets, so I have tried to
analyse various situations using the idea of sets and subsets and Venn
diagrams for demonstrating the relations between sets and subsets. The
idea is that the 'space' encompassed by a set in the diagram (labelled
as sets) is method functionality and attributes.
See diagram Case 1 (Class B is a subset of class A):
My understanding of inheritance in other languages is that Class A 'isa'
Class B, and inherits all of the attributes and
functionality of Class B, and extends functionality and attributes.
It is also possible for Class B to be ('isa') Class A, and ignore the
extra functionality of A, presumably to create objects that are smaller
than the more general class.
My suggested interpretation of roles:
Class B is a role, and Class A is built from Class B, extending its
functionality. A role without extra code becomes a class if it is
instantiated.
See diagram case 2 (Class A and Class B intersect):
Usual OO technique:
Class B inherits the functionality of Class A, extends the functionality
(in one 'direction') but then over-rides
(anuls) some of the functionality of A (say, by redefining
methods/attributes used in A).
Question: Is this the sort of behaviour that is forbidden in some languages.
Role-playing programming:
For the sake of programming sanity / ease of debugging, both Classes A
B are built from a role that represents their intersection ( Class A U
Class B), and then code is added in the definitions of the classes to
extend the functionality - possibly using over-riding with same-name
methods/attributes for different types.
See diagram case 3 (multiple subsets):
This would require multiple inheritance.
In perl6 (I think), Class A would be built from the 'roles' of classes B-D.
But the question is what would 'ref' (or perl6 equivalent) return? Would
it only define a match for (an object instantiated from) class A, or
would it recognise the existence of Classes B-D in that same object? If
so, how?
So suppose an object OA is an instance of class A and and object OB is
an instance of class (role) B. Would object OA 'match' object OB in some
form, after all the functionality of OB is contained within OA? But
then, this matching might not be transitive, viz. OA ~~ OB might be
true, but OB ~~ OA might be false because whilst OA contains the
functionality of OB, OB does not contain the functionality of OA.
See diagram case 4 (multiple intersecting sets):
I dont know how other OO languages handle this.
But with roles, they could be used to reflect the intersections, and
then the classes would be built from the roles.
Am I on the right track in understanding roles and multiple inheritance?
Regards,
Richard
Re: Implicit current-index variable, scoped inside for-loops
Carl Mäsak schreef:
Ruud:
Carl:
But maybe a variable that implicitly carries along the loop index
would be even snazzier?
for @array - $val {
say $.\t$val;
}
Or give the block a name (label), and have an index (or several
indexes, like some that are reset by redo an some that are not)
available, attached to that name.
That sounds like an interesting idea. Do you have a short snippet to
hint of what that would look like?
Maybe something like:
for @array - $val
{
say for.ix, \t$val;
}
for @array - $val NAME1:
{
say NAME1.ix, \t$val;
}
--
Affijn, Ruud
Gewoon is een tijger.
Re: Implicit current-index variable, scoped inside for-loops
Mark (), Carl ():
Yobert Hey do you know what would be cool in perl 6
Yobert A special variable for when you do a for (@array) style loop
Yobert it would always have the index of the array
Discussed on #perl6: it's already quite easy in Perl 6 to loop with an
explicit index:
my @array = moose elk caribou;
for @array.kv - $i, $val {
say $i\t$val;
}
But maybe a variable that implicitly carries along the loop index
would be even snazzier?
Whatever is done should also work for grep and map.
Oh, definitely.
In fact, you may just have found the raison d'etre for this feature. I
suppose doing a map or a grep over @array.kv is possible:
pugs my @array = london bridge is falling down
(london, bridge, is, falling, down)
pugs map { Element $^a is called $^b }: @array.kv;
(Element 0 is called london,
Element 1 is called bridge,
Element 2 is called is,
Element 3 is called falling,
Element 4 is called down)
But it can hardly be blamed for clarity.
--
masak
Re: Classes / roles as sets / subsets
See diagram case 2 (Class A and Class B intersect): B are built from a role that represents their intersection ( Class A U Class B), and then code is added in the definitions of the It may be just me being confused, but the symbol that looks like a U (U+222a) is usually union; intersection is the vertical reflection of that (U+2229). I'm not trying to be picky, but if it's confused me, it's probably confused someone else too. All of which reminds me, I'm looking forward to being able to iterate over my lists with \forall, \elem, and other set notation symbols rather than having to spell stuff out. Perl up to 5 may be executable line noise, but I can see Perl 6 being the closest thing yet to executable maths, and I love it. -- Always crash crash crashWell come on and let me know You're happy when I'm running bash Should I play or should I code? One test is fine, next is black(with apologies to The Clash) So if you want a dodgy hack worse at http://surreal.istic.org/songs pgpSXhIbc2Ap4.pgp Description: PGP signature
Re: Implicit current-index variable, scoped inside for-loops
Carl Mäsak schreef:
I suppose doing a map or a grep over @array.kv is possible:
pugs my @array = london bridge is falling down
(london, bridge, is, falling, down)
pugs map { Element $^a is called $^b }: @array.kv;
(Element 0 is called london,
Element 1 is called bridge,
Element 2 is called is,
Element 3 is called falling,
Element 4 is called down)
But it can hardly be blamed for clarity.
I find it very clear too. g
Also try a sparse array.
--
Affijn, Ruud
Gewoon is een tijger.
Re: Classes / roles as sets / subsets
On 8/29/06, Daniel Hulme [EMAIL PROTECTED] wrote: Perl up to 5 may be executable line noise, but I can see Perl 6 being the closest thing yet to executable maths, and I love it. Funny, I could have sworn APL was the closest thing yet to executable maths. ( Hey, wait a minute, I'm American; make that executable math. ) I think it's certainly closer than Perl6 will be. And yet, for all the talk about line noise, APL makes even the worst perl3 code look positively legible by comparison. :) -- Mark J. Reed [EMAIL PROTECTED]
Re: Implicit current-index variable, scoped inside for-loops
Having read this thread, I tend to think you're insane for bringing it
up again :-)
That said, I'll entertain the discussion for a bit ...
On Tue, Aug 29, 2006 at 08:33:20AM +0200, Carl Mäsak wrote:
Questions:
- Is the itch big enough for this? The more I look at the first piece
of code, the more I'm thinking that's not so bad, really. (Though
opinions differed on the IRC channel.) Is there a situation I'm not
thinking of where the first piece of code would suck, and the second
piece of code would rock? Or is this a case of oversugaring?
I think this is a case of too much sugar. I also think making the
variable *explicit* rather than implicit is a good thing.
Pointy blocks and .kv are simple and general and can be combined
in different ways for different contexts. A special index into the
iterator thingy doesn't sound that general. Just an observation.
- I feel there's a trend of moving away from line-noise variables. I'd
hate to be one to propose adding a new one to the language. Is there a
better syntax than $.?
Okay, stepping into the madness ...
If each iteratorish construct kept the iterator around in some easily
accessible way, then you could call methods on it. There is a trend
away from line-noisy variables, but given our iterator looks like =,
maybe the variable should be $= (hey, formats don't need it any more
;-)
for @array {
say The value $=.value is at index $=.index;
say The value $_ is at index $=.index;
}
I'd far and away rather say:
for @array.kv - $i, $v {
say The value $v is at index $i;
}
though.
Hmm. Now that I think about it a little more, $= will surely be
conflated with the PODish variables in some way. But, I don't have a
better alternative. (It's at this point that I wish there was a
double-underscore glyph on my keyboard just to have an alternative ;)
- How would this work with non-array data? Specifically, what happens
with next, redo etc on a filehandle, for example?
I would expect the index to track the iterator on next/redo. That is, if
you've read line 5, then the index will be 5ish (I'm hand waving 0- vs
1-based counting). On redo it would continue to be 5, and on next it
will be 6.
But what should happen when you're reading from multiple filehandles
or multiple arrays? Should it reset at the start of a new file/array
or continue counting? And how do you get the other behavior?
With the simple primitives we have now we can easily create whichever
behavior we desire. So, I think the extra sugar for some implicit
index will do more harm than good.
Here's one useful semantic I can think of WRT $= ... if it's a true
global (yes, I know we're supposed to be shy of those too, but I'm brain
storming here) then its scope lasts beyond the bounds of the block in
which it's executing so that things like
for @array { ... last if ...; }
say Stopped processing at $=.index;
work.
But, again, we have other ways of making this work that don't involve
introducing some implicit thing.
-Scott (PerlJam)
--
Jonathan Scott Duff [EMAIL PROTECTED]
Fwd: Classes / roles as sets / subsets
I accidently sent this directly to Richard. Sorry about that, folks...
-- Forwarded message --
From: Jonathan Lang [EMAIL PROTECTED]
Date: Aug 29, 2006 1:24 PM
Subject: Re: Classes / roles as sets / subsets
To: Richard Hainsworth [EMAIL PROTECTED]
Richard Hainsworth wrote:
I find classes and roles, and multiple inheritance in general, difficult
to understand. Larry Wall talked about subsets, so I have tried to
analyse various situations using the idea of sets and subsets and Venn
diagrams for demonstrating the relations between sets and subsets. The
idea is that the 'space' encompassed by a set in the diagram (labelled
as sets) is method functionality and attributes.
This may well miss the mark. Some of the most important differences
between classes and roles come in when the sets of method namespaces
don't match up with the sets of method implementations - that is, A
and B both include a method m, but A's method m does something
different than B's method m.
See diagram Case 1 (Class B is a subset of class A):
Note that in Case 1, there isn't much difference between classes and roles.
My understanding of inheritance in other languages is that Class A 'isa'
Class B, and inherits all of the attributes and
functionality of Class B, and extends functionality and attributes.
So far, so good. If you want A.m to do something different than B.m,
A redefines m.
It is also possible for Class B to be ('isa') Class A, and ignore the
extra functionality of A, presumably to create objects that are smaller
than the more general class.
Not according to clean OO programming theory. If A isa B, then A will
carry with it all of B's internal mechanisms, even the ones that it
has closed off from public access. If it fails to do this, it isn't
really a B. Even when A redefines how m works, it includes an
implicit mechanism for getting at the original definition. As such,
inheritance can only add to a class; it cannot remove or change
anything in any substantive manner. The only point at which stuff
gets removed is when the code optimizer comes along and trims the fat.
Let's extend Case 1 by adding a Class C, which is a superset of Class
A. C isa A, but A isa B; C can still access B.m, as well as A.m.
Think of A, B, and C as being layers that get added on top of each
other: A covers B, but doesn't actually replace it.
My suggested interpretation of roles:
Class B is a role, and Class A is built from Class B, extending its
functionality. A role without extra code becomes a class if it is
instantiated.
The motto for role A is anything you can do, I can do too. Note
that when role A declares that it does role B, it makes a promise
about _what_ it can do, but makes no promises about _how_ it will do
it. In fact, roles don't even make a promise to supply any
implementation information at all: B doesn't have to say a word about
how m works - and for the purpose of composing roles, what it _does_
say about how m works should be taken not so much as a rule than as a
guideline. As long as the composer has no reason _not_ to accept B's
version of m, it will; but at the first hint of trouble, B's version
of m will get jettisoned.
In Case 1, the only way that role B's version of m will get jettisoned
is if role A provides its own version. However, A is not a B; it is
its own unique entity. If A invalidates B's suggestion for how m
should work, then nothing that does A will implicitly have access to
B's version of m. Unlike classes, roles can change from what they're
composed from, not just add to them. However, because they don't
guarantee to tell you how anything works, they can't be used to
intantiate objects; that's what Classes are for.
See diagram case 2 (Class A and Class B intersect):
Usual OO technique:
Class B inherits the functionality of Class A, extends the functionality
(in one 'direction') but then over-rides
(anuls) some of the functionality of A (say, by redefining
methods/attributes used in A).
Question: Is this the sort of behaviour that is forbidden in some languages.
Very definitely, yes. Removing capabilities during inheritance is a
no-no. If you wanted Classes A abd B to be part of the same
inheritance tree, you'd have to define a common ancestor class that
contains the intersection of A and B, and then each of A and B inherit
from it.
As described, though, A and B are completely unrelated by inheritance;
each is a unique class which stands on its own. The fact that both
contain a method m is a coincidence, nothing more.
This _is_ a useful case to consider, though, in terms of what happens
if you add a new class (C) which encompasses both A and B. Assuming
that m is an element of both A and B, A.m doesn't neccessarily work
the same way as B.m; C.m needs to decide which version to use.
Traditionally, OO languages imnplement a system of seniority, where
one of the classes that C inherits from is given precedence over the
other - generally based on
Re: Implicit current-index variable, scoped inside for-loops
pugs map { Element $^a is called $^b }: @array.kv;
(Element 0 is called london,
Element 1 is called bridge,
Element 2 is called is,
Element 3 is called falling,
Element 4 is called down)
But it can hardly be blamed for clarity.
That's a little unfair. Choose good names and it's perfectly clear:
map { Element $^array_index is called $^array_value } == @array.kv;
Likewise, for your original formulation:
for @array {
say $^index\t$^value;
}
Given that we already have both placeholders (above) and pointy blocks:
for @array - $index, $value {
say $index\t$value;
}
to achieve this task, and given that both mechanisms allow you to choose the
name of the counter variable (rather than being stuck with some unreadable
punctuation variable), I don't think we need a third mechanism for this.
Damian
return Types: what are the enforcement details?
I'm interested in helping to write some tests for return types, but
I'd like some clarifications about them first. Are they just
declarations that help Perl optimize stuff, or they actually contracts?
As this little script shows, both inner and of are valid syntax now
with pugs, but neither is considered an error to throw an error when the
different type is actually returned.
I'd like see it documented in exactly what cases errors should be thrown
here.
For reference, return are described here:
http://feather.perl6.nl/syn/S06.html#Return_types
demo:
sub foo of Array {
my %h = ( a = 1 );
return %h;
}
sub zoo returns Array {
my %h = ( a = 1 );
return %h;
}
# Hashes are happily returned, despite the Array return types.
my %b = foo(); say %b.perl;
my %c = foo(); say %c.perl;
Perilous placeholder parameters
On 8/30/06, Damian Conway [EMAIL PROTECTED] wrote:
That's a little unfair. Choose good names and it's perfectly clear:
map { Element $^array_index is called $^array_value } == @array.kv;
As an aside, though, doesn't that particular solution now implicitly
rely on the fact that ('index' lt 'value')?
I get the feeling that if people want to give meaningful names to
their $^ parameters, they'll have to learn to start putting
predictable alphabetic prefixes in front of them.
($^a_index/$^b_value?)
Perhaps the lesson is that if you want something more descriptive than
$^a/$^b, you should be using a pointy block instead ...
Stuart
named arguments: What's the signature?
Regarding The S06 description of named arguments:
http://feather.perl6.nl/syn/S06.html#Named_arguments
What I find missing here is documentation of the signature to use
if you want to declare I accept an arbitrary number of named
arguments. (Like the param() methods common in Perl5 do).
Maybe it's the slurpy hash?
sub foo (*%h) {...} ?
The spec could use some clarification on this point.
Mark
Re: named arguments: What's the signature?
In a message dated Tue, 29 Aug 2006, Mark Stosberg writes:
Regarding The S06 description of named arguments:
http://feather.perl6.nl/syn/S06.html#Named_arguments
What I find missing here is documentation of the signature to use
if you want to declare I accept an arbitrary number of named
arguments. (Like the param() methods common in Perl5 do).
Maybe it's the slurpy hash?
sub foo (*%h) {...} ?
The spec could use some clarification on this point.
I think it's already there:
Slurpy parameters follow any required or optional parameters. They are
marked by a C* before the parameter:
sub duplicate($n, *%flag, [EMAIL PROTECTED]) {...}
Named arguments are bound to the slurpy hash (C*%flag
in the above example). Such arguments are evaluated in scalar context.
Any remaining variadic arguments at the end of the argument list
are bound to the slurpy array (C[EMAIL PROTECTED] above) and are evaluated
in list context.
Trey
Re: named arguments: What's the signature?
On 8/30/06, Mark Stosberg [EMAIL PROTECTED] wrote:
Regarding The S06 description of named arguments:
http://feather.perl6.nl/syn/S06.html#Named_arguments
What I find missing here is documentation of the signature to use
if you want to declare I accept an arbitrary number of named
arguments. (Like the param() methods common in Perl5 do).
Go down one section and read List parameters. (I agree that it's not
particularly explicit, and there probably should be a mention of it
under Named parameters.)
A06 also says:
A hash declaration like *%named indicates that the %named hash should
slurp up all the remaining named arguments (that is, those that aren't
bound explicitly to a specific formal parameter).
This description should probably be copied to the Synopsis.
Maybe it's the slurpy hash?
sub foo (*%h) {...} ?
Correct.
Stuart
A suggestion for a new closure trait.
Since a FIRST block gets called at loop initialization time, it seems to me
that it would be useful to have a block closure trait, RESUME, that gets
called at the beginning of every loop iteration except the first. Thus, at
the beginning of each loop iteration either FIRST or RESUME but not both
would get called. Other possible names for this block include REENTER,
SUBSEQUENT, or NOTFIRST.
RESUME would have many uses. For example, to put commas in the right places
in a printed list:
for @list - @value {
print $value;
RESUME {print ', ';} #If this were NEXT we would print an extra comma at
the end.
LAST {print \n;}
}
RESUME could also be useful for maintaining state information, such as loop
iteration or running sum, between loop iterations:
for @data - $value {
state $index will first {$_ = 0;} will resume {++$_;}
state $sum will first {$_ = $value;} will resume {$_ += value;}
...
}
Joe Gottman
Re: named arguments: What's the signature?
Trey Harris wrote:
Slurpy parameters follow any required or optional parameters. They are
marked by a C* before the parameter:
sub duplicate($n, *%flag, [EMAIL PROTECTED]) {...}
Named arguments are bound to the slurpy hash (C*%flag
in the above example). Such arguments are evaluated in scalar context.
Any remaining variadic arguments at the end of the argument list
are bound to the slurpy array (C[EMAIL PROTECTED] above) and are evaluated
in list context.
So would this mean zero or more pairs of named arguments, or one or more:
sub foo (*%h)
I expected this:
sub foo (*%h) # one more pairs
sub foo (*%h?) # zero or more pairs
The answer with pugs now is different:
sub foo (*%h) # zero or more pairs
sub foo (%h, *%h), # one or more pairs
If pugs behavior is intended, I think it should be documented in the
spec, as I found unintuitive.
Mark
Re: Implicit current-index variable, scoped inside for-loops
Damian Conway schreef: [attribution repaired] Carl: But it can hardly be blamed for clarity. That's a little unfair. can hardly be blamed - can easily be praised g -- Affijn, Ruud Gewoon is een tijger.
Re: Implicit current-index variable, scoped inside for-loops
But it can hardly be blamed for clarity. That's a little unfair. can hardly be blamed - can easily be praised g Apologies to Carl if I misinterpreted. I read it as: can hardly be blamed for (having) clarity ;-) Damian
could 'given' blocks have a return value?
Sometimes I use 'given' blocks to set a value. To save repeating myself
on the right hand side of the given block, I found I kept want to do this:
my $foo = given { }
...and have whatever value that was returned from when {} or default {}
populate $foo.
It turns out pugs already allow this, through the trick of wrapping the
given block in an anonymoose sub...which is then immediately executed:
my $rm = sub { given $rm_param {
when Code { $rm_param(self) }
when Hash { %rm_paramrun_mode }
default{ self.query.param($rm_param) }
}}();
Not only do you get implicit matching on the left side, you get implicit
return values on the right!
I'd just like to be able to clean that up a little to:
my $rm = given $rm_param {
when Code { $rm_param(self) }
when Hash { %rm_paramrun_mode }
default{ self.query.param($rm_param) }
};
Mark
Re: Implicit current-index variable, scoped inside for-loops
Damian Conway schreef:
Ruud:
Damian:
Carl:
But it can hardly be blamed for clarity.
That's a little unfair.
can hardly be blamed - can easily be praised g
Apologies to Carl if I misinterpreted. I read it as:
can hardly be blamed for (having) clarity
;-)
Nah, I was just joking; his but gave it away already.
I didn't agree that the map-approach Carl showed is not clear, but
prefer the pointy blocks version that you showed.
my @array = london bridge is falling down ;
for @array - $index, $value
{
say Element $_ is called $value
}
But I don't understand how the $index, $value pair gets its values; is
@array somehow turned into a hash with the index as the key?
With @array - $index, $value {}, is $_ an alias of $index?
--
Affijn, Ruud (should update his pugs, but on dialup now)
Gewoon is een tijger.
Re: Implicit current-index variable, scoped inside for-loops
for @array - $index, $value
{
say Element $_ is called $value
}
But I don't understand how the $index, $value pair gets its values; is
@array somehow turned into a hash with the index as the key?
With @array - $index, $value {}, is $_ an alias of $index?
No. There's no such magic. I simply screwed up. I should have written:
for @array.kv - $index, $value {...}
:-(
Damian
Re: could 'given' blocks have a return value?
Mark Stosberg wrote:
Sometimes I use 'given' blocks to set a value. To save repeating myself
on the right hand side of the given block, I found I kept want to do this:
my $foo = given { }
...and have whatever value that was returned from when {} or default {}
populate $foo.
Isn't it still the case that the last expression evaluated within a
closure is returned by the closure? And isn't a given block just a
fancy kind of closure?
The question is whether or not a code block can be used where the
parser expects an expression; for instance, could one say:
my $foo = if condition {BAR} else {BAZ};
?
I'm no expert, but it occurs to me that allowing this could be a
parsing nightmare.
ISTR a programming construct along the lines of eval that is
effectively shorthand for sub { ... }().
It turns out pugs already allow this, through the trick of wrapping the
given block in an anonymoose sub...which is then immediately executed:
my $rm = sub { given $rm_param {
when Code { $rm_param(self) }
when Hash { %rm_paramrun_mode }
default{ self.query.param($rm_param) }
}}();
Not only do you get implicit matching on the left side, you get implicit
return values on the right!
I'd just like to be able to clean that up a little to:
my $rm = given $rm_param {
when Code { $rm_param(self) }
when Hash { %rm_paramrun_mode }
default{ self.query.param($rm_param) }
};
So what happens if you forget to include a default in the given?
--
Jonathan Dataweaver Lang
Re: could 'given' blocks have a return value?
On 8/30/06, Mark Stosberg [EMAIL PROTECTED] wrote:
Sometimes I use 'given' blocks to set a value. To save repeating myself
on the right hand side of the given block, I found I kept want to do this:
my $foo = given { }
According to S04, given {} is at statement level, so you can't use it
directly as an expression. But Perl 6 always allow you to say
my $foo = do given {...}
As well as
my $foo = do if foo {...} else {...}
my $rm = sub { given $rm_param {
when Code { $rm_param(self) }
when Hash { %rm_paramrun_mode }
default{ self.query.param($rm_param) }
}}();
Apparently ``do'' is a simplified version for this. :)
Cheers,
Agent
Questions about statement modifiers
Hi, there~
I think S04 says too little about statement modifiers. Please comment
on the following code samples. Are they valid Perl 6?
do { say } for 1..3;
{ say } for 1..3;
- $i { say $i } for 1..3;
And how about similar variations for other statement modifiers, such
as while, given, if, until, and unless?
Thanks!
Agent
