Re: [perl #61126] return should apply to the lexically enclosing routine, map is no exception
Daniel (), Carl ():
The above reasoning raises the following question for me: how do I
return from a sub or a method from within a map block?
I suppose what you want can be achieved with last, it probably should
work in map as well, since map and for are synonims...
That is all good and well for exiting the map itself; but what I want
to achieve is to exit the surrounding sub or method block. Example:
sub foo {
...
my @a = map {
...
return if $condition; # return from foo
...
}, @a;
...
}
Except that, as you explained, the above will not return from foo,
but only from the map call. How would I return from foo?
// Carl
Re: [perl #61126] return should apply to the lexically enclosing routine, map is no exception
Em Dom, 2008-12-07 às 18:10 +0100, Carl Mäsak escreveu: The above reasoning raises the following question for me: how do I return from a sub or a method from within a map block? I suppose what you want can be achieved with last, it probably should work in map as well, since map and for are synonims... daniel
Re: [perl #61126] return should apply to the lexically enclosing routine, map is no exception
Em Seg, 2008-12-08 às 12:08 +0100, Carl Mäsak escreveu:
Daniel (), Carl ():
That is all good and well for exiting the map itself; but what I want
to achieve is to exit the surrounding sub or method block. Example:
Er... I mean actually the opposite... it should always return from the
surrounding sub or method, never only from map, if you want to end
the map loop, you should use last... meaning...
sub foo {
map { last; }, 1, 2, 3; # executes the block only once
map { return; }, 1, 2, 3; # returns from foo;
}
daniel
[perl #61130] :nth() does not work with :x() or :g in .subst in Rakudo
On Sun Dec 07 07:24:07 2008, masak wrote:
The .subst method in Rakudo r33599 can understand :x()...
$ perl6 -e 'say foo1foo2foo3foo4.subst(foo, bar, :x(2))' # yes
bar1bar2foo3foo4
...and :nth()...
$ perl6 -e 'say foo1foo2foo3foo4.subst(foo, bar, :nth(2))' # yes
foo1bar2foo3foo4
...and :g...
$ perl6 -e 'say foo1foo2foo3foo4.subst(foo, bar, :g)' # yes
bar1bar2bar3bar4
...but not :x() together with :nth()...
$ perl6 -e 'say foo1foo2foo3foo4.subst(foo, bar, :x(2),
:nth(2))' # expected foo1bar2foo3bar4
foo1bar2foo3foo4
...and not :g together with :nth().
$ perl6 -e 'say foo1foo2foo3foo4.subst(foo, bar, :g, :nth(2))' #
expected foo1bar2foo3bar4
foo1bar2foo3foo4
The above are my personal expectations. The current version of S05 is
silent on how :nth() interacts with :x() and :g. There are spectests
for :g:nth but not (as far as I can see) for :x:nth.
Since your personal expectations are the same as mine, I took the liberty to
turn our expectations into spec tests, in
t/spec/S05-substitution/subst.t (pugs r24207).
The reasoning behind it is quite simple: I imagine :g to mean the same as
:x(*). Now a :x($x) and :nth($n) interact like this:
for 1 .. $x {
match here
if ($x-1) % $n == 0 {
do substitution
}
}
(CC'ing p6l, since it defines language semantics, albeit just a bit)
Re: [perl #61130] :nth() does not work with :x() or :g in .subst in Rakudo
On Sun, Dec 07, 2008 at 03:09:30PM -0800, Moritz Lenz via RT wrote:
...but not :x() together with :nth()...
$ perl6 -e 'say foo1foo2foo3foo4.subst(foo, bar, :x(2),
:nth(2))' # expected foo1bar2foo3bar4
foo1bar2foo3foo4
The above are my personal expectations. The current version of S05 is
silent on how :nth() interacts with :x() and :g. There are spectests
for :g:nth but not (as far as I can see) for :x:nth.
Since your personal expectations are the same as mine, I took the liberty to
turn our expectations into spec tests, in
t/spec/S05-substitution/subst.t (pugs r24207).
The reasoning behind it is quite simple: I imagine :g to mean the same as
:x(*). Now a :x($x) and :nth($n) interact like this:
for 1 .. $x {
match here
if ($x-1) % $n == 0 {
do substitution
}
}
(CC'ing p6l, since it defines language semantics, albeit just a bit)
The problem with this reasoning is that :nth doesn't have to be an
integer -- S05 also allows things like
:nth(1,2,3,5,8,13)
:nth({.is_fibonacci})
It's not immediately obvious how those forms of :nth would interact
with :x or :g.
The way to do something like replace every 3rd occurrence would
seem to be to do things like:
:nth({ $_ % 3 == 0 })
:nth(3..*:by(3))
Another problem is that :x($n) specifies perform $n substitutions,
such that if we say :x(4) and there aren't four things to substitute,
then none of the substitutions take place.
At the moment I think that :x specifies a constraint on the
total number of substitutions that are (must be) performed,
while :nth selects the candidate matches to be substituted.
Thus
.subst( $pat, $rep, :nth(1,4,9,16,25,36), :x(4) )
would perform substitutions on the 1st, 4th, 9th, and 16th matches,
and do nothing if at least sixteen matches were not found.
Pm
Re: [perl #61126] return should apply to the lexically enclosing routine, map is no exception
Daniel (), Carl ():
That is all good and well for exiting the map itself; but what I want
to achieve is to exit the surrounding sub or method block. Example:
Er... I mean actually the opposite... it should always return from the
surrounding sub or method, never only from map, if you want to end
the map loop, you should use last... meaning...
sub foo {
map { last; }, 1, 2, 3; # executes the block only once
map { return; }, 1, 2, 3; # returns from foo;
}
Ok, I realize I've been misunderstanding both your bug report and your
stated opinion when we talked about this on #perl6 the other day. I
thought you wanted 'return' inside a map block to act as if it were
within an invisible sub body (making both snippets of code in the
ticket return 2 instead of 1). Your actual request makes much more
sense. :)
As a plus side, I now suddenly understand what you mean by 'return'
being lexically bound. That's both DWIMmy and cool.
// Carl
Re: Files, Directories, Resources, Operating Systems
* Mark Overmeer [EMAIL PROTECTED] [2008-12-07 14:20]: So why are you all so hessitating in making each other's life easier? There is no 100% solution, but 0% is even worse! It looks like Python 3000 just tried that. People are not happy about it: http://utcc.utoronto.ca/~cks/space/blog/python/OsListdirProblem Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: Files, Directories, Resources, Operating Systems
On Mon, Dec 8, 2008 at 8:16 PM, Aristotle Pagaltzis [EMAIL PROTECTED] wrote: It looks like Python 3000 just tried that. People are not happy about it: http://utcc.utoronto.ca/~cks/space/blog/python/OsListdirProblem Yeeh, I also noted exactly that problem when reading the What's New In Python 3.0. What were they thinking?! Leon
Re: Files, Directories, Resources, Operating Systems
* Aristotle Pagaltzis ([EMAIL PROTECTED]) [081208 19:16]: * Mark Overmeer [EMAIL PROTECTED] [2008-12-07 14:20]: So why are you all so hessitating in making each other's life easier? There is no 100% solution, but 0% is even worse! It looks like Python 3000 just tried that. People are not happy about it: http://utcc.utoronto.ca/~cks/space/blog/python/OsListdirProblem I thought we were having a serious discussion. We all know that considering all names as Unicode is a stupid presumption. It seems that some bright minds got stuck in a deep recursion about codesets in file- and directory names. A pitty that we do not focus on the general concept of OS abstraction (knowing that some problems are only partially solvable (on the moment)). -- MarkOv Mark Overmeer MScMARKOV Solutions [EMAIL PROTECTED] [EMAIL PROTECTED] http://Mark.Overmeer.net http://solutions.overmeer.net
Out of CONTROL...?
A very interesting question came up on #perl today, so I'm
forwarding it to p6l for discussion/decision.
Given the following code:
sub foo() { return 1; }
sub bar() { warn oops; }
{
CONTROL { ... }
foo();
bar();
}
S04 seems to clearly indicate that the CONTROL block above would
be invoked by the Cwarn exception thrown by bar(). The #perl6
question is, do the same semantics apply for Creturn -- i.e.,
would the return exception thrown in foo() also invoke the
CONTROL block in the caller?
Both interpretations have validity, which is why I'm bringing
it here for further reflection and guidance.
Pm
