n 2016)
Changed paths:
M S04-control.pod
Log Message:
---
[S04] Add missing parenthesis in zip() example
Commit: 21525aab69789f0d7a00640d75ae332d4fad9e73
https://github.com/perl6/specs/commit/21525aab69789f0d7a00640d75ae332d4fad9e73
Author: niner <n...@deton
p 2015)
Changed paths:
M S04-control.pod
Log Message:
---
S04: Fix pre-GLR-ism
isn't it wonderful how much simpler this passage becomes through the GLR?
p 2015)
Changed paths:
M S04-control.pod
Log Message:
---
De-Parcel-ify S04
paths:
M S04-control.pod
Log Message:
---
Revert addition of 'slip' to S04
'slip' may (or may not) be a nice+useful feature, but we're not ready to
add it to core just now. In GLR we have more pressing concerns.
This reverts commit 24850d6b665913be797067a5c80e8d3fdfc03c1b
paths:
M S04-control.pod
Log Message:
---
typo in S04
paths:
M S04-control.pod
Log Message:
---
[S04] small nit
let and temp are prefix operators, not ordinary functions
paths:
M S04-control.pod
Log Message:
---
[S04] note one more that eval does not catch exceptions
paths:
M S04-control.pod
Log Message:
---
[S04] un-spec method-level PRE/POST
The intent was to extend block-level PRE/POST to something that could
do Eiffel-style Design-by-Contract assertions. This is an intriguing
idea, but not in the way the spec outlined it. See
http
paths:
M S04-control.pod
Log Message:
---
[S04] unspec submethod PRE/POST
See http://irclog.perlgeek.de/perl6/2012-03-11#i_5275742 for the
discussion that precipitated their removal. Anyone with a
working implementation of them is free to add them back. :-)
S04-control.pod
Log Message:
---
Fix self-contradiction in S04
Branch: refs/heads/master
Home: http://github.com/perl6/specs
Commit: a826b588b613ef61471e4d89c6b86d7f3502dcdb
http://github.com/perl6/specs/commit/a826b588b613ef61471e4d89c6b86d7f3502dcdb
Author: TimToady la...@wall.org
Date: 2010-09-06 (Mon, 06 Sep 2010)
Changed paths:
M S04
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-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-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-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: 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: 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
--- S04-control.pod.orig 2009-08-11 08:43:36.0 +0100
+++ S04-control.pod 2009-08-11 09:03:42.0 +0100
@@ -1232,6 +1232,21 @@
before CBEGIN, CCHECK, or CINIT, since those are done at compile or
process initialization time).
+If an exception is thrown through a block without a CCATCH
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
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 result. If you
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 p6l.
I'm also
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 before, as I haven't been following
$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 of undefined value
b: 1
c: 1
As a followup question, what about...?
my @array;
for 1..3 - $x
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 contribute.
In S04
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
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 multiple exceptions.
So what
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 unordered then
we also maximize
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
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 think of
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 forall keyword (and a
givenall keyword corresponding to given) would be a good idea.
These would not be quite parallel to for and given because there
would
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 forall keyword (and a
givenall keyword corresponding to given) would be a good idea.
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
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
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 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
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
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
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 unordered then
we also maximize the number
On Fri, Jan 04, 2008 at 01:13:11PM -0800, Dave Whipp wrote:
From that
perspective, it's unfortunate a Cfor loop always iterates arrays in the
order of their indices.
But it doesn't, in hyper context. In Perl 6, Cfor and Cmap are
really the same thing, and both respond to hyper context.
As
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).
No;
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
be the
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
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 names)
are Cforall; and a form
statements that are missing from S04 (feel free to change the names)
are Cforall; and a form of Cgiven that tests/executes multiple
Cwhen clauses in arbitrary order (without needing the sequential
Ccontinue statement).
forall @a - $x { ... }
runs the code block on each element
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
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
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
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
.
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
From S10
AUTODEF, CANDO
Submethods
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.
(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
, 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
Pseudo-class from S12
WALK
I might've missed some.
So making statement
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 has
I know, shoot me -- but just so we've discussed it and put it to bed,
maybe :if or _if or fi?
shudders
--- 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
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
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 curlies.
As of yesterday you can get very close
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 up both the keywords and the curlies
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 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;
:
:
Larry Wall schreef:
Maybe we should just make statement modifiers
uppercase and burn out everyone's eye sockets. :)
Or maybe
{
}.
while $x ;
--
Groet, Ruud
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,
This quote from S04
quote
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
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 close to this by putting a space-eating
backslash after
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 digitally signed
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
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
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
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
Index: S04.pod
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 it by p6l for review/comments
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
pass it by p6l
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,
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 the
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:
if $dbh {
my $sth will undo
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 the corresponding block-level trait.
Not really. `will` is just defined
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]
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
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 long
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
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) };
last
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
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 is a loop
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
83 matches
Mail list logo
