:
M S04-control.pod
Log Message:
---
[S04] Add missing parenthesis in zip() example
Commit: 21525aab69789f0d7a00640d75ae332d4fad9e73
https://github.com/perl6/specs/commit/21525aab69789f0d7a00640d75ae332d4fad9e73
Author: niner
Date: 2016-01-17 (Sun, 17 Jan 2016
Branch: refs/heads/master
Home: https://github.com/perl6/specs
Commit: 3f0277cff77649169b8854470c13220f16b8db57
https://github.com/perl6/specs/commit/3f0277cff77649169b8854470c13220f16b8db57
Author: Moritz Lenz
Date: 2015-09-19 (Sat, 19 Sep 2015)
Changed paths:
M S04
Branch: refs/heads/master
Home: https://github.com/perl6/specs
Commit: 558155b811176632b4e00366df2d40c5eeb89cfc
https://github.com/perl6/specs/commit/558155b811176632b4e00366df2d40c5eeb89cfc
Author: Moritz Lenz
Date: 2015-09-05 (Sat, 05 Sep 2015)
Changed paths:
M S04
Branch: refs/heads/master
Home: https://github.com/perl6/specs
Commit: 3be145ca3e36f03fa3832cd25c939fc315472fdf
https://github.com/perl6/specs/commit/3be145ca3e36f03fa3832cd25c939fc315472fdf
Author: Carl Masak
Date: 2014-10-24 (Fri, 24 Oct 2014)
Changed paths:
M S04
Branch: refs/heads/master
Home: https://github.com/perl6/specs
Commit: 12b6d9f6ea29b46898272d024de5cb81b5d8649d
https://github.com/perl6/specs/commit/12b6d9f6ea29b46898272d024de5cb81b5d8649d
Author: diakopter
Date: 2013-02-26 (Tue, 26 Feb 2013)
Changed paths:
M S04
Branch: refs/heads/master
Home: https://github.com/perl6/specs
Commit: 8c3efe4bf60065452c453cae3e7d4187e750d1be
https://github.com/perl6/specs/commit/8c3efe4bf60065452c453cae3e7d4187e750d1be
Author: Moritz Lenz
Date: 2012-05-27 (Sun, 27 May 2012)
Changed paths:
M S04
Branch: refs/heads/master
Home: https://github.com/perl6/specs
Commit: 536a4833099b1313d14705df5fb10ee073b3a5e5
https://github.com/perl6/specs/commit/536a4833099b1313d14705df5fb10ee073b3a5e5
Author: Moritz Lenz
Date: 2012-04-09 (Mon, 09 Apr 2012)
Changed paths:
M S04
Branch: refs/heads/master
Home: https://github.com/perl6/specs
Commit: 937f37f7e03a53a6ee167556ab7ab4f0d14c43ae
https://github.com/perl6/specs/commit/937f37f7e03a53a6ee167556ab7ab4f0d14c43ae
Author: Carl Masak
Date: 2012-03-11 (Sun, 11 Mar 2012)
Changed paths:
M S04
Branch: refs/heads/master
Home: https://github.com/perl6/specs
Commit: 578e3cbf3189098e7e854d6222905218d7e67ebc
https://github.com/perl6/specs/commit/578e3cbf3189098e7e854d6222905218d7e67ebc
Author: Carl Masak
Date: 2012-03-11 (Sun, 11 Mar 2012)
Changed paths:
M S04
Branch: refs/heads/master
Home: https://github.com/perl6/specs
Commit: 6828ff448731bb0c5327f6202159e4b1a448654e
https://github.com/perl6/specs/commit/6828ff448731bb0c5327f6202159e4b1a448654e
Author: Stefan O'Rear
Date: 2011-03-05 (Sat, 05 Mar 2011)
Changed paths:
M S04-contro
Branch: refs/heads/master
Home: http://github.com/perl6/specs
Commit: a826b588b613ef61471e4d89c6b86d7f3502dcdb
http://github.com/perl6/specs/commit/a826b588b613ef61471e4d89c6b86d7f3502dcdb
Author: TimToady
Date: 2010-09-06 (Mon, 06 Sep 2010)
Changed paths:
M S04-control.pod
M S32
Author: lwall
Date: 2010-07-15 01:53:05 +0200 (Thu, 15 Jul 2010)
New Revision: 31691
Modified:
docs/Perl6/Spec/S04-control.pod
Log:
[S04] more bombastic utterances about not dropping pending exceptions
Modified: docs/Perl6/Spec/S04-control.pod
Author: lwall
Date: 2010-07-15 01:32:07 +0200 (Thu, 15 Jul 2010)
New Revision: 31690
Modified:
docs/Perl6/Spec/S04-control.pod
Log:
[S04] revise catcher semantics semantics to allow $!.handled = 1 to work as
well as case match
Modified: docs/Perl6/Spec/S04-control.pod
Author: lwall
Date: 2010-07-12 21:52:08 +0200 (Mon, 12 Jul 2010)
New Revision: 31645
Modified:
docs/Perl6/Spec/S04-control.pod
Log:
[S04] try to nail down CATCH exit semantics a bit more water-tightly
Modified: docs/Perl6/Spec/S04-control.pod
Author: lwall
Date: 2010-07-10 00:59:12 +0200 (Sat, 10 Jul 2010)
New Revision: 31610
Modified:
docs/Perl6/Spec/S04-control.pod
Log:
[S04] emphasize that LEAVE blocks *always* run even under stack unwinding
Modified: docs/Perl6/Spec/S04-control.pod
Author: lwall
Date: 2010-07-09 23:10:45 +0200 (Fri, 09 Jul 2010)
New Revision: 31601
Modified:
docs/Perl6/Spec/S04-control.pod
Log:
[S04] simplify definition of successful return to be context agnostic
define class-level PRE/POST to be submethods that are called like BUILD/DESTROY
Modified
Author: sorear
Date: 2010-07-03 06:39:32 +0200 (Sat, 03 Jul 2010)
New Revision: 31532
Modified:
docs/Perl6/Spec/S04-control.pod
Log:
[S04] Clarify interaction of lexical classes and packages with members after
discussion with TimToady
Modified: docs/Perl6/Spec/S04-control.pod
it wrong.
Ben
--- S04-control.pod.orig 2009-08-11 08:43:36.00000 +0100
+++ S04-control.pod 2009-08-11 09:03:42.0 +0100
@@ -1232,6 +1232,21 @@
before C, C, or C, since those are done at compile or
process initialization time).
+If an exception is thrown through a block without a C b
Moritz Lenz wrote:
Ben Morrow wrote:
- Presumably when an exception is thrown through a block, the LEAVE and
POST queues are called (in that order).
POST was inspired from the Design By Contract department, and are meant
to execute assertions on the result. If you leave a block through an
e
Ben Morrow wrote:
> Moritz Lenz wrote:
>> Ben Morrow wrote:
>>>
>>> - Presumably when an exception is thrown through a block, the LEAVE and
>>> POST queues are called (in that order).
>>
>> POST was inspired from the Design By Contract department, and are meant
>> to execute assertions on the re
Ben Morrow wrote:
> I'm iworking on a patch for Perl 5 that implements the Perl 6 closure
> traits (ENTER/LEAVE/...) as special blocks. There are several details
> that aren't clear to me from either S04 or the spec tests; I apologize
> if these have been discussed bef
I'm iworking on a patch for Perl 5 that implements the Perl 6 closure
traits (ENTER/LEAVE/...) as special blocks. There are several details
that aren't clear to me from either S04 or the spec tests; I apologize
if these have been discussed before, as I haven't been following p6
amp;get_x; }
> $b = foo();
> }
>
> my $c = foo();
>
> say "a: ", $a();
> say "b: ", $b();
> say "c: ", $c();
If I'm reading the current version of S04 correctly,
I'm guessing the above will produce
a: Use
Larry Wall larry-at-wall.org |Perl 6| wrote:
No, just the new exception, which merely has to contain the old
unhandled exceptions somehow in case the user wants more information.
OK, so it's more like the "inner exception" in Microsoft's .NET
framework. My C++ exceptions have always had t
On Wed, Sep 03, 2008 at 06:44:22PM -0500, John M. Dlugosz wrote:
> I'm trying to work out some details of this area, but I don't understand
> what S04 is trying to say. Could someone please point me in the right
> direction? I'd be happy to then edit the S04 to contr
I'm trying to work out some details of this area, but I don't understand what S04 is
trying to say. Could someone please point me in the right direction? I'd be happy to
then edit the S04 to contribute.
In S04, the "Exceptions" section mentions that $! contains mult
What would be the expected output from the following?
my $a = foo();
my $b;
{
my $x = 1;
sub get_x() { return $x; }
sub foo() { return &get_x; }
$b = foo();
}
my $c = foo();
say "a: ", $a();
say "b: ", $b();
say "c: ", $c();
As
On Fri, 2008-01-11 at 10:34 -0800, Dave Whipp wrote:
> Matthew Walton wrote:
>
> > I wouldn't agree with that at all. I think of arrays as ordered constructs,
> > so I'd want the default iteration over my array to happen in the order of
> > the indices.
>
> I guess that depends on whether you th
Matthew Walton wrote:
I wouldn't agree with that at all. I think of arrays as ordered constructs,
so I'd want the default iteration over my array to happen in the order of
the indices.
I guess that depends on whether you think of the array as a list or as a
ram. I know that a group at microso
appropriate underlying machinery is there, so
> maybe I can live with the bias in S04 -- perhaps rename it to
> "Sequential Blocks and Statements". Anywhere that we guarantee
> sequential behavior, we pretty much rule out concurrency. But if we
> maximize the number of places w
Larry Wall wrote:
my hope is that we can delegate locking entirely to the innards of
the implementation and never mention it at all on the language level.
Hmm, sounds to me analogous to hoping that type inference will avoid the
need to expose type-annotations at the language level (synchroniz
Larry Wall wrote:
> I (impersonally) believe that hyper context is the right solution to
> this because context can propagate to where it needs to dynamically.
> As for the fact that it's not the default list context for "for",
> that could easily be changed with a pragma. Maybe that could even
>
Dave Whipp wrote:
> No, you're not the only person thinking Occam ... though I should point
> out that none of my suggestions are "par" blocks -- a par block made
> every statement within the block execute in parallel with the other
> statements in that block (much like a Verilog fork/join pair).
On Fri, Jan 04, 2008 at 01:13:11PM -0800, Dave Whipp wrote:
> From that
> perspective, it's unfortunate a C loop always iterates arrays in the
> order of their indices.
But it doesn't, in hyper context. In Perl 6, C and C are
really the same thing, and both respond to hyper context.
> As I see
ng machinery is there, so
maybe I can live with the bias in S04 -- perhaps rename it to
"Sequential Blocks and Statements". Anywhere that we guarantee
sequential behavior, we pretty much rule out concurrency. But if we
maximize the number of places where we are explicitly "unorder
Joe Gottman schreef:
> if code that should be processed concurrently
> is instead processed sequentially, the results will be correct
Not if parallel sampling of happening stuffs is involved. All of your
thousands of temperature sensors in your nuclear factory, all running
the same code, should n
I (impersonally) believe that hyper context is the right solution to
this because context can propagate to where it needs to dynamically.
As for the fact that it's not the default list context for "for",
that could easily be changed with a pragma. Maybe that could even
be the default someday, but
> I disagree with the idea that humans don't think concurrently (though
> more often they think in terms of data dependencies).
I think this is more analogous to event based programming rather than parallel
programming. Event based and parallel based have some similarities but the
are fundament
Mark J. Reed wrote:
Am I the only one having bad flashbacks to Occam, here? (Transputing Will
Change Everything!)
My $0.02, FWIW:
Concurrency is surprising. Humans don't think that way. And programs
aren't written that way - any program represented as a byte stream is
inherently sequential i
Am I the only one having bad flashbacks to Occam, here? (Transputing Will
Change Everything!)
My $0.02, FWIW:
Concurrency is surprising. Humans don't think that way. And programs
aren't written that way - any program represented as a byte stream is
inherently sequential in nature.
Where the s
Luke Palmer wrote:
forall was about concurrency, not order of evaluation. There is a difference
between running in an arbitrary order serially and running in parallel.
for %bag {
.say;
}
If the bag had elements "hello", "world", I think printing:
helworld
lo
Would defi
On Jan 4, 2008 9:18 AM, Jonathan Lang <[EMAIL PROTECTED]> wrote:
> Joe Gottman wrote:
> >On the other hand, this being Perl, I do believe it should be easy to
> > specify the concurrent case. I think that a keyword (and a
> > keyword corresponding to ) would be a good idea.
> > These would n
Joe Gottman wrote:
>On the other hand, this being Perl, I do believe it should be easy to
> specify the concurrent case. I think that a keyword (and a
> keyword corresponding to ) would be a good idea.
> These would not be quite parallel to and because there
> would be some subtle differen
-on feature.
Two statements that are missing from S04 (feel free to change the
names) are C; and a form of C that tests/executes
multiple C clauses in arbitrary order (without needing the
sequential C statement).
forall @a -> $x { ... }
runs the code block on each element of @a (no defi
ers, which is
why I called out S04 specifically. The concern I have is that it is
necessary to use a "functional" subset to explicitly tell Perl6 that I
want it to do the right thing on many-core systems.
The bias that I see is the perceived need to say that hypers (and
junctio
At 5:22 PM -0800 1/2/08, Dave Whipp wrote:
I was reading Synopsis 4 with regards to multi core programming. It
seems to be infused with a bias towards non-parallel models of
computation. Concurrently appears to be an add-on feature -- whereas
we should have a mindset that explicit sequential co
ints are the
> add-on feature.
That sounds really like a bad idea for simple "just do it" scripts. Just
imagine explaining concurrency issue to a beginner who is not even
confident with variables and blocks...
> Two statements that are missing from S04 (feel free to change the na
statements that are missing from S04 (feel free to change the names)
are C; and a form of C that tests/executes multiple
C clauses in arbitrary order (without needing the sequential
C statement).
forall @a -> $x { ... }
runs the code block on each element of @a (no defined order). If @a i
In the "Multiplicative Precedence" section of S04, "div" is specified twice.
Joe Gottman
Am Mittwoch, 26. Juli 2006 03:18 schrieb Ruud H.G. van Tol:
> Thomas Wittek schreef:
> >
> > What I wanted to say is that it would annoy me, if almost all
> > operators and control-flow keywords are lowercase but a hand full of
> > them has to be written uppercase.
Hi,
I suppose the above is a s
This is a patch for S04. Special thanks go to cjeris++ and other kind
persons on #perl6 for reviewing this.
Cheers,
Agent
Index: D:/projects/Perl6-Syn/S04.pod
===
--- D:/projects/Perl6-Syn/S04.pod (revision 10479)
+++ D
Thomas Wittek schreef:
> Actually I don't know all of them but most seem to be (part of)
> identifiers, not operators. Of course they are reserved words.
>
> What I wanted to say is that it would annoy me, if almost all
> operators and control-flow keywords are lowercase but a hand full of
> them
TER, CALLER, CONTEXT, SUPER, COMPILING
> Closure traits from S04
> BEGIN, CHECK, INIT, END, FIRST, ENTER, LEAVE, KEEP,
> UNDO, NEXT, LAST, PRE, POST, CATCH, CONTROL
> From S10
> AUTODEF, CANDO
> Submethods from S12
> BUILD, BUILDALL, CREATE, DESTROY, DESTROYALL
> Pse
(This paragraph may need some more treatment but I won't attempt
it until I grasp the content better.)
* agentzh++ noticed confusing language regarding two kinds of scope
in S04.
--- design/syn/S04.pod (revision 10465)
+++ design/syn/S04.pod (working copy)
@@ -456,7 +456,7 @@
of
On 7/25/06, Thomas Wittek <[EMAIL PROTECTED]> wrote:
> Bearing that in mind, would the eye-socket-burning
>
> return $foo
> IF $something;
>
> really be so bad?
Operators/reserved words should be lowercase. Period. ;)
I think that this would heavily break consistency, annoying new users.
ency, annoying new users.
There are already many uppercase reserved words in perl6:
Pseudo-packages from S02
MY, OUR, GLOBAL, OUTER, CALLER, CONTEXT, SUPER, COMPILING
Closure traits from S04
BEGIN, CHECK, INIT, END, FIRST, ENTER, LEAVE, KEEP,
UNDO, NEXT, LAST, PRE, POST, CATCH, CONTROL
F
> Bearing that in mind, would the eye-socket-burning
>
> return $foo
> IF $something;
>
> really be so bad?
Operators/reserved words should be lowercase. Period. ;)
I think that this would heavily break consistency, annoying new users.
-Thomas
On 7/22/06, Aaron Crane <[EMAIL PROTECTED]> wrote:
Larry Wall writes:
> Maybe we should just make statement modifiers uppercase and burn out
> everyone's eye sockets. :)
...
Bearing that in mind, would the eye-socket-burning
return $foo
IF $something;
really be so bad?
This has
I know, shoot me -- but just so we've discussed it and put it to bed,
maybe :if or _if or fi?
--- Aaron Crane <[EMAIL PROTECTED]> wrote:
> Larry Wall writes:
> > Maybe we should just make statement modifiers uppercase and burn
> out
> > everyone's eye sockets. :)
>
> I like statement modifie
Larry Wall writes:
> Maybe we should just make statement modifiers uppercase and burn out
> everyone's eye sockets. :)
I like statement modifiers, and I want them to continue to exist in Perl 6.
But it seems to me that a lot of the most awkward decisions about Perl 6
syntax are awkward precisely b
In a message dated Fri, 21 Jul 2006, Ruud H.G. van Tol writes:
Larry Wall schreef:
Maybe we should just make statement modifiers
uppercase and burn out everyone's eye sockets. :)
Or maybe
{
}.
while $x ;
Actually, can't that be made to work already (already by the language
spec, not
Larry Wall schreef:
> Maybe we should just make statement modifiers
> uppercase and burn out everyone's eye sockets. :)
Or maybe
{
}.
while $x ;
--
Groet, Ruud
On Fri, Jul 21, 2006 at 12:07:52PM -0500, Jonathan Scott Duff wrote:
: Or just give them some sort of syntactic marker ... I know!
:
: loop {
: ...
: }
: :while $loopy;
:
: eat :if $hungry;
: go_postal :when $aggravation > 10;
: .sleep :until .rested;
:
: *Everybo
On Thu, Jul 20, 2006 at 10:18:57AM -0700, Larry Wall wrote:
> It ain't easy. Maybe we should just make statement modifiers uppercase
> and burn out everyone's eye sockets. :)
Or just give them some sort of syntactic marker ... I know!
loop {
...
}
:while $loopy;
eat :if
On Thu, Jul 20, 2006 at 05:03:32PM +0100, Smylers wrote:
: Markus Laire writes:
:
: > S04 seems to say that a style like this can't be used by
: > perl6-programmers:
: >
: > loop
: > {
: >...
: > }
: > while $x;
: >
: > I like this style, as it lines u
On 7/20/06, Smylers <[EMAIL PROTECTED]> wrote:
Markus Laire writes:
> S04 seems to say that a style like this can't be used by
> perl6-programmers:
>
> loop
> {
>...
> }
> while $x;
>
> I like this style, as it lines up both the keywords and the c
Markus Laire writes:
> S04 seems to say that a style like this can't be used by
> perl6-programmers:
>
> loop
> {
>...
> }
> while $x;
>
> I like this style, as it lines up both the keywords and the curlies.
As of yesterday you can get very clos
This quote from S04
Outside of any kind of expression brackets, a final closing curly on a
line (not counting whitespace or comments) always reverts to the
precedence of semicolon whether or not you put a semicolon after it.
(In the absence of an explicit semicolon, the current statement may
l_flow/
goto.t in particular needs to include all the S04 forms; I have sent
you a commit bit -- please checkout http://svn.openfoundry.org/pugs
with Subversion, add yourself to AUTHORS, and change/augment goto.t
to include those test cases.
Thanks!
Audrey
PGP.sig
Description: This is a d
I picked this up at the YAPC and made some markups on it. Apologies
that it is not in a diff format, but that's going to come with practice.
I got stuck on some of the intended behaviors and prohibited behaviors
of the 'goto' function. For the purpose of clarity would it be useful
to provide
On Mon, Oct 24, 2005 at 07:39:23AM +0300, Ilmari Vacklin wrote:
: Hi,
:
: S04 says thus:
:
: The default case:
:
: default {...}
:
: is exactly equivalent to
:
: when true {...}
:
: However, that parses to:
:
: if $_ ~~ bool::true { ...; leave }
:
: Which is not
On 10/23/05, Ilmari Vacklin <[EMAIL PROTECTED]> wrote:
> Hi,
>
> S04 says thus:
>
> The default case:
>
> default {...}
>
> is exactly equivalent to
>
> when true {...}
>
> However, that parses to:
>
> if $_ ~~ boo
Hi,
S04 says thus:
The default case:
default {...}
is exactly equivalent to
when true {...}
However, that parses to:
if $_ ~~ bool::true { ...; leave }
Which is not executed if $_ is false, unless ~~ bool::true does
something special. Perhaps default should be
Autrijus asked:
On Wed, Jun 15, 2005 at 05:37:18PM -0500, Patrick R. Michaud wrote:
Based on an off-list discussion, it turns out that unary C<=>
is not slurpy as mentioned in S04. The following patch to S04
corrects this; I've already applied the patch but thought I'd
pa
On Wed, Jun 15, 2005 at 05:37:18PM -0500, Patrick R. Michaud wrote:
> Based on an off-list discussion, it turns out that unary C<=>
> is not slurpy as mentioned in S04. The following patch to S04
> corrects this; I've already applied the patch but thought I'd
> pass i
Based on an off-list discussion, it turns out that unary C<=>
is not slurpy as mentioned in S04. The following patch to S04
corrects this; I've already applied the patch but thought I'd
pass it by p6l for review/comments/reactions.
Pm
On Mon, May 02, 2005 at 03:20:03PM -0700, Larry Wall wrote:
: Probably does something like:
:
: &?BLOCK does First; # no-op if it already does First
: &?BLOCK.firstlist.push(&block);
Probably shouldn't use up a normal name like "First" for that. Maybe we
can just reuse the trait name as
On Fri, Apr 29, 2005 at 10:57:01AM -0500, David Christensen wrote:
: 1) What type of introspection, if any, are we providing to the language
: level? I.e., are we providing something along the lines of
:
: %traits = &?BLOCK.traits
:
: where %traits is keyed on trait name (FIRST, LAST, whate
;m just going off of the synopses, which if definite
> clarification on some of these issues has been made, should probably be
> updated to reflect the decisions made.)
>
> Firstly, it is suggested in S04 that variables indicated with a "will"
> predicate contribute to
larification on some of these issues has been made, should probably be
updated to reflect the decisions made.)
Firstly, it is suggested in S04 that variables indicated with a "will"
predicate contribute to the corresponding block-level trait. I.e., if
we have the following bit of code:
On Thu, Feb 10, 2005 at 09:45:59AM -0800, Larry Wall wrote:
> That's spelled
>
> loop {
> $foo = readline;
> ...do stuff with $foo...
> } while ( $foo );
>
> these days.
>
> Larry
Cool, perfect. Thanks.
--Dks
--
[EMAIL PROTECTED]
On Thu, 2005-02-10 at 11:59, Luke Palmer wrote:
> There's been some discussion about bringing a syntax back for that
> recently, but I haven't really been paying attention. Anyway, this is
> pretty clear:
>
> loop {
> $foo = readline;
> do { stuff :with($foo) };
> las
On Thu, Feb 10, 2005 at 07:39:54AM -0800, David Storrs wrote:
: Given that Perl 6 won't support an actual do-while loop a la C++ (and
: yes, I know that Perl5 didn't either), how would you accomplish that?
: That is, I'd like to have a loop that runs once, then checks its
: condition to see if it s
David Storrs writes:
> Given that Perl 6 won't support an actual do-while loop a la C++ (and
> yes, I know that Perl5 didn't either), how would you accomplish that?
> That is, I'd like to have a loop that runs once, then checks its
> condition to see if it should repeat and continues to repeat as l
Given that Perl 6 won't support an actual do-while loop a la C++ (and
yes, I know that Perl5 didn't either), how would you accomplish that?
That is, I'd like to have a loop that runs once, then checks its
condition to see if it should repeat and continues to repeat as long
as the condition is true.
Thank you for your fast and detailed reply.
Larry Wall skribis 2005-01-29 11:08 (-0800):
> On Sat, Jan 29, 2005 at 05:59:40PM +0100, Juerd wrote:
> : Can last/redo be used outside loops? (i.e. with if or given)
> No, though of course what "loop" means is negotiable. Effectively,
> anything that c
On Sat, Jan 29, 2005 at 05:59:40PM +0100, Juerd wrote:
: Some questions after reading S04:
:
:
: Can last/redo be used outside loops? (i.e. with if or given)
No, though of course what "loop" means is negotiable. Effectively,
anything that captures the appropriate control exceptions
Some questions after reading S04:
Can last/redo be used outside loops? (i.e. with if or given)
Is a bare block still a loop?
Can loop be used as a statement modifier? (say 'y' loop;)
Can OUTER be stacked? ($OUTER::OUTER::_)
TIA.
Juerd
88 matches
Mail list logo
