Re: Synchronized / Thread syntax in Perl 6
--- Larry Wall <[EMAIL PROTECTED]> wrote:
> On Sat, Jun 03, 2006 at 03:51:45PM -0700, Paul Hodges wrote:
> : { no threads;
> :print @_.»();
> : }
>
> It seems a bit odd to use a construct for its syntactic sugar value
> but take away its semantics...
>
> If you just need ordering, this (or something like it) should
> serialize it:
>
>print $_.() for @_;
>
> Larry
LOL -- and "d'oh".
Apologies, not enough sleep.
I stand corrupted. :o]
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
[svn:perl6-synopsis] r9466 - doc/trunk/design/syn
Author: larry
Date: Sat Jun 3 20:43:33 2006
New Revision: 9466
Modified:
doc/trunk/design/syn/S03.pod
Log:
typo from scook0++
Modified: doc/trunk/design/syn/S03.pod
==
--- doc/trunk/design/syn/S03.pod(original)
+++ doc/trunk/design/syn/S03.podSat Jun 3 20:43:33 2006
@@ -132,7 +132,7 @@
?TERM # any single term coerced to boolean
!TERM # any single term coerced to boolean
@a[SIMPLE] # any of these simples used as subscript recursively
-%a[SIMPLE] # any of these simples used as subscript recursively
+%a{SIMPLE} # any of these simples used as subscript recursively
We also include:
[svn:perl6-synopsis] r9465 - doc/trunk/design/syn
Author: larry
Date: Sat Jun 3 20:32:43 2006
New Revision: 9465
Modified:
doc/trunk/design/syn/S03.pod
Log:
Revisions to definitions of simple scalar.
Modified: doc/trunk/design/syn/S03.pod
==
--- doc/trunk/design/syn/S03.pod(original)
+++ doc/trunk/design/syn/S03.podSat Jun 3 20:32:43 2006
@@ -116,14 +116,37 @@
and imply scalar assignment:
$a # simple scalar variable
-@a[123]# single literal subscript
-%a{'x'}# single literal subscript
+@a[SIMPLE] # single simple subscript
+%a{SIMPLE} # single simple subscript
%a # single literal subscript
-@a[+TERM] # single term coerced to numeric for array
-%a{~TERM} # single term coerced to string for hash
+
+Where SIMPLE is defined as
+
+123# single literal
+'x'# single literal
+"$x" # single literal
+qq/$x/ # single literal
++TERM # any single term coerced to numeric
+-TERM # any single term coerced to numeric
+~TERM # any single term coerced to string
+?TERM # any single term coerced to boolean
+!TERM # any single term coerced to boolean
@a[SIMPLE] # any of these simples used as subscript recursively
%a[SIMPLE] # any of these simples used as subscript recursively
+We also include:
+
+OP SIMPLE
+SIMPLE OP
+SIMPLE OP SIMPLE
+
+where C is includes any standard scalar operators in the five
+precedence levels autoincrement, exponentiation, symbolic unary,
+multiplicative, and additive; but these are limited to standard
+operators that are known to return numbers, strings, or booleans.
+(Operators that imply list operations are excluded: C<$>, C<@>,
+and C, for instance. Hyper operators are also excluded.)
+
All other forms imply list assignment, and will evaluate both sides
of the assignment in list context (eventually). However, this is
primarily a syntactic distinction, and no semantic or type information
Re: [svn:perl6-synopsis] r9463 - doc/trunk/design/syn
On 6/4/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
+$a # simple scalar variable
+@a[123]# single literal subscript
+%a{'x'}# single literal subscript
+%a # single literal subscript
+@a[+TERM] # single term coerced to numeric for array
+%a{~TERM} # single term coerced to string for hash
+@a[SIMPLE] # any of these simples used as subscript recursively
+%a[SIMPLE] # any of these simples used as subscript recursively
Typo alert: that last one should be %a{SIMPLE}, right?
Stuart
[svn:perl6-synopsis] r9463 - doc/trunk/design/syn
Author: larry
Date: Sat Jun 3 19:45:11 2006
New Revision: 9463
Modified:
doc/trunk/design/syn/S03.pod
Log:
Change default lvalue parsing to default to list, with short list of scalars.
Modified: doc/trunk/design/syn/S03.pod
==
--- doc/trunk/design/syn/S03.pod(original)
+++ doc/trunk/design/syn/S03.podSat Jun 3 19:45:11 2006
@@ -12,9 +12,9 @@
Maintainer: Larry Wall <[EMAIL PROTECTED]>
Date: 8 Mar 2004
- Last Modified: 19 May 2006
+ Last Modified: 3 Jun 2006
Number: 3
- Version: 35
+ Version: 36
=head1 Changes to existing operators
@@ -109,22 +109,35 @@
loop ($a = 1, $b = 2; ; $a++, $b++) {...}
-still works fine. The distinction between scalar and list assignment
-is similar to the way Perl 5 does it. If there are parens around
-the left side, or if the variable is an array or hash, it's a list
-assignment. Otherwise it's a scalar assignment. One difference from
-Perl 5 is that Perl 6 does not attempt to intuit whether an lvalue
-slice is meant to be one element or several, so you must use parens
-in that case. This is true even if you put something that is obviously
-a list as the subscript:
-
-@x[1,2,3] = 4,5,6; # WRONG
-(@x[1,2,3]) = 4,5,6; # correct
-
-These parens actually apply list context on both sides:
-
-@x[foo()] = bar(); # foo() and bar() both in scalar context
-(@x[foo()]) = bar(); # foo() and bar() both in list context
+still works fine. The distinction between scalar and list
+assignment is similar to the way Perl 5 does it, but has to be a
+little different because we can no longer decide on the basis of
+the sigil. The following forms are defined as "obviously simple",
+and imply scalar assignment:
+
+$a # simple scalar variable
+@a[123]# single literal subscript
+%a{'x'}# single literal subscript
+%a # single literal subscript
+@a[+TERM] # single term coerced to numeric for array
+%a{~TERM} # single term coerced to string for hash
+@a[SIMPLE] # any of these simples used as subscript recursively
+%a[SIMPLE] # any of these simples used as subscript recursively
+
+All other forms imply list assignment, and will evaluate both sides
+of the assignment in list context (eventually). However, this is
+primarily a syntactic distinction, and no semantic or type information
+is used, since it influences subsequent parsing. In particular, even
+if a function is known to return a scalar value from its declaration,
+you must use C<+> or or C<~> to use it as a scalar within a subscript:
+
+@a[foo()] = bar(); # foo() and bar() called in list context
+@a[+foo()] = bar();# foo() and bar() called in scalar
context
+
+(But note that the first form still works fine if C and C
+are scalar functions that are not context sensitive. The difference
+in parsing is only an issue if C is followed by a comma or
+some such.)
=item * List operators are all parsed consistently. As in Perl 5,
to the left they look like terms, while to the right they look like
[svn:perl6-synopsis] r9462 - doc/trunk/design/syn
Author: larry Date: Sat Jun 3 19:13:10 2006 New Revision: 9462 Modified: doc/trunk/design/syn/S12.pod Log: Clarified scoping of "has $x" and friends. Modified: doc/trunk/design/syn/S12.pod == --- doc/trunk/design/syn/S12.pod(original) +++ doc/trunk/design/syn/S12.podSat Jun 3 19:13:10 2006 @@ -12,9 +12,9 @@ Maintainer: Larry Wall <[EMAIL PROTECTED]> Date: 27 Oct 2004 - Last Modified: 8 May 2006 + Last Modified: 3 Jun 2006 Number: 12 - Version: 15 + Version: 16 =head1 Overview @@ -360,14 +360,26 @@ Public attributes have a secondary sigil of "dot", indicating the automatic generation of an accessor method of the same name. Private attributes use an exclamation to indicate that no public accessor is -generated. The exclamation is optional, so these are identical in effect: +generated. has $!brain; -has $brain; -And any later references to the private variable may either use or -omit the exclamation, as you wish to emphasize or ignore the privacy -of the variable. +The "true name" of the private variable always has the exclamation, but +much like with C variables, you may declare a lexically scoped alias +to the private variable by saying: + +has $brain;# also declares $!brain; + +And any later references to the private variable within the same block +may either use or omit the exclamation, as you wish to emphasize or +ignore the privacy of the variable. Outside the block, you must use +the C form. If you declare with the C form, you must use that +form consistently everywhere. If you declare with the C<.> form, you +also get the private C form as a non-virtual name for the actual +storage location, and you may use either C or C<.> form anywhere +within the class, even if the class is reopened. Outside the class +you must use the public C<.> form, or rely on a method call (which +can be a private method call, but only for trusted classes). For public attributes, some traits are copied to the accessor method. The C trait causes the generated accessor to be declared C,
Re: Synchronized / Thread syntax in Perl 6
On Sat, Jun 03, 2006 at 03:51:45PM -0700, Paul Hodges wrote:
: --- Ashley Winters <[EMAIL PROTECTED]> wrote:
: > On 6/2/06, Paul Hodges <[EMAIL PROTECTED]> wrote:
: > >
: > > my @answer = map { async { &_() } } @jobs;
: >
: > That still seems too explicit. I thought we had hyperoperators to
: > implictly parallelize for us:
: >
: > my @answer = @jobs.»();
: >
: > Which would run them in parallel automatically, if possible.
:
: Snazzy bit of syntactic shenanigans, that...and slick, if we're in that
: mode, but just to clarify, I *will* still be able to know whether or
: not something's going to thread? Or will it matter?
Shouldn't, if the hyperop is really promising that the calls won't
interact, and that's how hyper is currently defined. I think Best
Practices will not have hypers spawning huge interacting threads.
: Seems to me there will be times when I WANT a purely single-threaded
: system, even if I'm using hyperops -- in fact, especially if I'm using
: hyperops. Maybe we need a pragma to be able to step in and out as
: needed?
:
: { no threads;
:print @_.»();
: }
It seems a bit odd to use a construct for its syntactic sugar value but
take away its semantics...
If you just need ordering, this (or something like it) should serialize it:
print $_.() for @_;
Larry
Re: Synchronized / Thread syntax in Perl 6
--- Ashley Winters <[EMAIL PROTECTED]> wrote:
> On 6/2/06, Paul Hodges <[EMAIL PROTECTED]> wrote:
> >
> > my @answer = map { async { &_() } } @jobs;
>
> That still seems too explicit. I thought we had hyperoperators to
> implictly parallelize for us:
>
> my @answer = @jobs.»();
>
> Which would run them in parallel automatically, if possible.
Snazzy bit of syntactic shenanigans, that...and slick, if we're in that
mode, but just to clarify, I *will* still be able to know whether or
not something's going to thread? Or will it matter?
Seems to me there will be times when I WANT a purely single-threaded
system, even if I'm using hyperops -- in fact, especially if I'm using
hyperops. Maybe we need a pragma to be able to step in and out as
needed?
{ no threads;
print @_.»();
}
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Re: Synchronized / Thread syntax in Perl 6
On 6/2/06, Paul Hodges <[EMAIL PROTECTED]> wrote:
Though if that works, you could squish this example even more, to
class QueueRunner {
our sub process_queue(Code @jobs_in) {
map { async { &_() } } @jobs_in;
}
}# end QueueRunner
# Elsewhere...
my @answer = QueueRunner.process_job_queue( @jobs );
and the issues of serialization are hidden in the map() call. For all
that
my @answer = map { async { &_() } } @jobs;
though that gets away from the point.
Someone smack me if I'm drifting too far here?
That still seems too explicit. I thought we had hyperoperators to
implictly parallelize for us:
my @answer = @jobs.»();
Which would run them in parallel automatically, if possible.
- Ashley Winters
[svn:perl6-synopsis] r9435 - doc/trunk/design/syn
Author: audreyt
Date: Sat Jun 3 05:49:52 2006
New Revision: 9435
Modified:
doc/trunk/design/syn/S04.pod
Log:
* S04 - Change this example:
if -e { say "exists" } { extra() }
to this:
if rand { say "exists" } { extra() }
Because bare "-e" may be removed along with all $_-defaulting forms
(to be replaced by .-e), but bare "rand" defaults to 1, and as such
should probably be still there.
Modified: doc/trunk/design/syn/S04.pod
==
--- doc/trunk/design/syn/S04.pod(original)
+++ doc/trunk/design/syn/S04.podSat Jun 3 05:49:52 2006
@@ -12,9 +12,9 @@
Maintainer: Larry Wall <[EMAIL PROTECTED]>
Date: 19 Aug 2004
- Last Modified: 5 May 2006
+ Last Modified: 3 June 2006
Number: 4
- Version: 20
+ Version: 21
This document summarizes Apocalypse 4, which covers the block and
statement syntax of Perl.
@@ -638,18 +638,18 @@
in front of it will be taken as terminating the conditional, even if
the conditional expression could take another argument. Therefore
-if -e { say "exists" } { extra() }
-if -e -> $x { say "exists" } { extra() }
+if rand { say "exists" } { extra() }
+if rand -> $x { say "exists" } { extra() }
is always parsed as
-if (-e) { say "exists" }; { extra() }
-if (-e) -> $x { say "exists" }; { extra() }
+if (rand) { say "exists" }; { extra() }
+if (rand) -> $x { say "exists" }; { extra() }
rather than
-if (-e { say "exists" }) { extra() }
-if (-e (-> $x { say "exists" })) { extra() }
+if (rand { say "exists" }) { extra() }
+if (rand (-> $x { say "exists" })) { extra() }
Apart from that, it is illegal to use a bare closure where an
operator is expected. (Remove the whitespace if you wish it to be
[svn:perl6-synopsis] r9442 - doc/trunk/design/syn
Author: audreyt Date: Sat Jun 3 07:12:04 2006 New Revision: 9442 Modified: doc/trunk/design/syn/S05.pod Log: * At scw++'s request, add an explicit definition to the default : "\s+ if it's between two \w characters, \s* otherwise" Modified: doc/trunk/design/syn/S05.pod == --- doc/trunk/design/syn/S05.pod(original) +++ doc/trunk/design/syn/S05.podSat Jun 3 07:12:04 2006 @@ -14,9 +14,9 @@ Maintainer: Patrick Michaud <[EMAIL PROTECTED]> and Larry Wall <[EMAIL PROTECTED]> Date: 24 Jun 2002 - Last Modified: 13 May 2006 + Last Modified: 3 June 2006 Number: 5 - Version: 24 + Version: 25 This document summarizes Apocalypse 5, which is about the new regex syntax. We now try to call them I because they haven't been @@ -631,8 +631,10 @@ / /# was /(?=pattern)/ / / # was /(? /# match whitespace by :s policy / /# match the SPACE character (U+0020) + / /# match "whitespace": + # \s+ if it's between two \w characters, + # \s* otherwise / / # match only at a particular StrPos # short for
Re: About default options ':ratchet' and ':sigspace' on rules
在 2006/6/3 下午 3:03 時，Shu-Chun Weng 寫到： I'll then rewrite most of my rules into tokens. And about the definition of , the "engine" I mentioned is Pugs::Complier::Rule, so that if what PGE does is considered the "correct" way, I will change the behavior of P::C::Rule. Yes, please do. :-) By the way, if someone can add it to S05 would make me more comfortable. Done as r9442. Cheers, Audrey
Re: About default options ':ratchet' and ':sigspace' on rules
Hi,
Thanks for the comments :)
I'll then rewrite most of my rules into tokens. And about the
definition of , the "engine" I mentioned is Pugs::Complier::Rule,
so that if what PGE does is considered the "correct" way, I will
change the behavior of P::C::Rule. By the way, if someone can add
it to S05 would make me more comfortable.
Shu-Chun Weng
On Fri, Jun 02, 2006 at 09:03:18AM -0500, Patrick R. Michaud wrote:
> On Fri, Jun 02, 2006 at 02:17:25PM +0800, Shu-chun Weng wrote:
> > 1. Spaces at beginning and end of rule blocks should be ignored
> > since space before and after current rule are most likely be
> > defined in rules using current one.
> > 1a. I'm not sure if it's "clear" to define as this, but the spaces
> > around the rule-level alternative could also be ignored.
>
> At one point I had been exploring along similar lines, but at the
> moment I'd say we don't want to do this. See below for an example...
>
> > For instance, look at the rule FunctionAppExpr defined in
> > MiniPerl6 grammar file.
> >
> >rule FunctionAppExpr
> > {|||[?<'('>?<')'>]?}
>
> FWIW, I'd go ahead and write this as a token statement instead of
> a rule:
>
> token FunctionAppExpr {
> |
> |
> |
> | [ \( \) ]?
> }
>
> In fact, now that I've written the above I'm more inclined to say
> it's not a good idea to ignore some whitespace in rule definitions
> but not others. Consider:
>
> rule FunctionAppExpr {
> |
> |
> |
> | [ \( \) ]?
> }
>
> Can we quickly determine where the are being generated?
> What if the [...] portion had an alternation in it?
>
> (And, if we ignore leading/trailing whitespace in rule blocks, do
> we also ignore leading/trailing whitespace in subpatterns?)
>
> In a couple of grammars I've developed already (especially the
> one used for pgc.pir), having whitespace at the beginning of rules
> and around alternations become is useful and important.
> In these cases, ignoring such whitespace would mean adding explicit
> in the rule to get things to work. At that point it feels like
> waterbed theory -- by "improving" things for the FunctionAppExpr
> rule above we're pushing the complexity somewhere else.
>
> In general I'd say that in a production such as FunctionAppExpr
> where there are just a few places that need , then it's
> better to use 'token' and explicitly indicate the allowed
> whitespace.
>
> (Side observation: in
> ...|[?<'('>?<')'>]?}
> above, there's no whitespace between and the closing paren.
> Why not?)
>
> > 2. I am not sure the default rule of , I couldn't found it in
> > S05. Currently the engine use :P5/\s+/ but I would like it to
> > be :P/\s*/ when it's before or after non-words and remains
> > the same (\s+) otherwise.
>
> PGE does the "\s* when before or after non-words and \s+ otherwise"
> explicitly in its rule, which is written in PIR. (Being able
> to write subrules procedurally is I nice.)
>
> In P5 it'd probably be something like
>
> (?:(?
> or maybe better is
>
> (?:(?
> Pm
