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 ?ws, 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
{Variable|Constants|ArrayRef|FunctionName[?ws?'('?ws?Parameters')']?}
FWIW, I'd go ahead and write this as a token statement instead of
a rule:
token FunctionAppExpr {
| Variable
| Constants
| ArrayRef
| FunctionName [ ?ws \( ?ws Parameters \) ]?
}
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 {
| Variable
| Constants
| ArrayRef
| FunctionName[ \( Parameters \) ]?
}
Can we quickly determine where the ?ws 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 ?ws is useful and important.
In these cases, ignoring such whitespace would mean adding explicit
?ws 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 ?ws, then it's
better to use 'token' and explicitly indicate the allowed
whitespace.
(Side observation: in
...|FunctionName[?ws?'('?ws?Parameters')']?}
above, there's no whitespace between Parameters and the closing paren.
Why not?)
2. I am not sure the default rule of ws, 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 ws rule, which is written in PIR. (Being able
to write subrules procedurally is Ireally nice.)
In P5 it'd probably be something like
(?:(?!\w)|(?!\w))\s*|\s+
or maybe better is
(?:(?!\w)|(?!\w)|\s)\s*
Pm
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 ?ws, 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
[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 ws:
\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 Iregex because they haven't been
@@ -631,8 +631,10 @@
/ before pattern /# was /(?=pattern)/
/ after pattern / # was /(?pattern)/
- / ws /# match whitespace by :s policy
/ sp /# match the SPACE character (U+0020)
+ / ws /# match whitespace:
+ # \s+ if it's between two \w characters,
+ # \s* otherwise
/ at($pos) / # match only at a particular StrPos
# short for ?{ .pos == $pos }
[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
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
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 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
[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 Cour 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 Crw trait causes the generated accessor to be declared Crw,
[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
+%ax # 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 Cfoo() and Cbar()
+are scalar functions that are not context sensitive. The difference
+in parsing is only an issue if Cbar() 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
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
+%ax # 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] 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
%ax # 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 COP 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 Cxx, 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
[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:
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
