Fwd: Insurrection account created
Moin, who is phase-n and why do they create accounts for CPAN users? best wishes, Tels -- Forwarded Message -- Subject: Insurrection account created Date: Wednesday 10 May 2006 14:12 From: "Insurrection Administrator" <[EMAIL PROTECTED]> To: "New Insurrection User" <[EMAIL PROTECTED]> A user access account has been created on the Insurrection Server for username [EMAIL PROTECTED] by user adam Your initial random password is: You can change your password via http://svn.phase-n.com/password.cgi Please go to http://svn.phase-n.com/ for information and documentation about the Insurrection server. This EMail was produced on Wednesday, May 10, 2006 at 12:12 GMT The request was done from 58.178.90.125 The user agent was Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.0.3) Gecko/20060426 Firefox/1.5.0.3 -- Insurrection Server - http://svn.phase-n.com/ --- -- Signed on Thu May 11 10:01:25 2006 with key 0x93B84C15. Visit my photo gallery at http://bloodgate.com/photos/ PGP key on http://bloodgate.com/tels.asc or per email. This email violates U.S. patent #5,546,528 and EU patent EP0689133: | Header | Body | Attachements | | |+ +--| | | ~ ~ A user access account has been created on the Insurrection Server for username [EMAIL PROTECTED] by user adam Your initial random password is: sMpkW6fPAcZ You can change your password via http://svn.phase-n.com/password.cgi Please go to http://svn.phase-n.com/ for information and documentation about the Insurrection server. This EMail was produced on Wednesday, May 10, 2006 at 12:12 GMT The request was done from 58.178.90.125 The user agent was Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.0.3) Gecko/20060426 Firefox/1.5.0.3 -- Insurrection Server - http://svn.phase-n.com/ pgp09uoSLIyJ5.pgp Description: PGP signature
Re: Fwd: Insurrection account created
Phase N is my company, and http://svn.phase-n.com/svn/cpan is the collaborative subversion repository for my code, that now includes PPI, which you've expressed a desire to have bugs fixed in I believe a number of times. http://use.perl.org/~Alias/journal/29327 Did you not get the email about a minute after than one that said, in response to your rt.cpan.org comments about wanting the PPI bugs fixed. (paraphrasing) "I don't have time right now, but I've added you to my repository so you can fix them yourself" :) As for the cpan accounts, Insurrection (the svn repo manager) uses email-based accounts, and so I have been linking account for CPAN people to their @cpan.org email addresses. Adam K Tels wrote: Moin, who is phase-n and why do they create accounts for CPAN users? best wishes, Tels -- Forwarded Message -- Subject: Insurrection account created Date: Wednesday 10 May 2006 14:12 From: "Insurrection Administrator" <[EMAIL PROTECTED]> To: "New Insurrection User" <[EMAIL PROTECTED]> A user access account has been created on the Insurrection Server for username [EMAIL PROTECTED] by user adam Your initial random password is: You can change your password via http://svn.phase-n.com/password.cgi Please go to http://svn.phase-n.com/ for information and documentation about the Insurrection server. This EMail was produced on Wednesday, May 10, 2006 at 12:12 GMT The request was done from 58.178.90.125 The user agent was Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.0.3) Gecko/20060426 Firefox/1.5.0.3 -- Insurrection Server - http://svn.phase-n.com/ ---
[svn:parrot-pdd] r12611 - trunk/docs/pdds
Author: leo
Date: Thu May 11 01:48:18 2006
New Revision: 12611
Modified:
trunk/docs/pdds/pdd03_calling_conventions.pod
Log:
pdd03 typo
Modified: trunk/docs/pdds/pdd03_calling_conventions.pod
==
--- trunk/docs/pdds/pdd03_calling_conventions.pod (original)
+++ trunk/docs/pdds/pdd03_calling_conventions.pod Thu May 11 01:48:18 2006
@@ -332,7 +332,7 @@
foo(x, ar :flat, y) # flattening array
foo(p, 'q' => q)# named argument
foo(p, q :named('q')) # the same
- foo(kw :named :flat)# a flattening has
+ foo(kw :named :flat)# a flattening hash
=head2 Parameters
[svn:perl6-synopsis] r9176 - doc/trunk/design/syn
Author: autrijus
Date: Thu May 11 02:52:17 2006
New Revision: 9176
Modified:
doc/trunk/design/syn/S06.pod
Log:
* S06: "but true" is now spelled as "but True"
Modified: doc/trunk/design/syn/S06.pod
==
--- doc/trunk/design/syn/S06.pod(original)
+++ doc/trunk/design/syn/S06.podThu May 11 02:52:17 2006
@@ -1575,7 +1575,7 @@
sub system {
...
return $error but false if $error;
-return 0 but true;
+return 0 but True;
}
Properties are predeclared as roles and implemented as mixins--see S12.
Re: A rule by any other name...
On 2006-May-10 at 1:38, James Mastros wrote:
>Can I suggest we keep match meaning thing you get when you run a thingy
>against a string, and make "matcher" be the thingy that gets run?
Speaking of the word "match", what I'd really like is to keep it meaning stuff
that matches. Unfortunately it also seems to get used to mean an "attempted
match", which, if it fails, is not a match at all. This leads to the phrase
"successful match", which sounds a bit bizarre and is redundant in ordinary
English. S05 uses "match" in both senses, and more than once I had to, er,
backtrack to figure out which meaning was intended.
Obviously, good words are needed for both meanings: "match" should always stand
for a "successful match" ('cause that's what the word actually means), and some
other term for the act of comparing two things to see whether or not they do
happen to match. (The word "compare" comes to mind.)
-David "grudge match" Green
Info from Devel::Cover
I've got a guy at work who wants to take coverage reports and bung them in a database so he can track historical coverage data. As I see it, he needs to somehow parse the stuff in cover_db/ but neither he nor I understand what's in there. Do any modules already exist for this? I believe the thing that generates the coverage reports currently is C code or something? So isn't there anything CPANish to do this? K. -- Kirrily Robert -- [EMAIL PROTECTED] -- http://infotrope.net/
Re: A rule by any other name...
[EMAIL PROTECTED] schreef:
> James Mastros:
>> Can I suggest we keep match meaning thing you get when you run a
>> thingy against a string, and make "matcher" be the thingy that gets
>> run?
>
> Speaking of the word "match", what I'd really like is to keep it
> meaning stuff that matches. Unfortunately it also seems to get used
> to mean an "attempted match", which, if it fails, is not a match at
> all. This leads to the phrase "successful match", which sounds a bit
> bizarre and is redundant in ordinary English. S05 uses "match" in
> both senses, and more than once I had to, er, backtrack to figure out
> which meaning was intended.
>
> Obviously, good words are needed for both meanings: "match" should
> always stand for a "successful match" ('cause that's what the word
> actually means), and some other term for the act of comparing two
> things to see whether or not they do happen to match. (The word
> "compare" comes to mind.)
Great, a match to light a language contest.
A match can be partial, a loose matching bolt can crash a(n
aero| )plane.
A match has context, like with clothes: a suiting match, a matching
suit.
:)
--
Groet, Ruud
Re: [svn:perl6-synopsis] r9176 - doc/trunk/design/syn
On Thursday 11 May 2006 5:52 am, [EMAIL PROTECTED] wrote: > * S06: "but true" is now spelled as "but True" > > ... > return $error but false if $error; > -return 0 but true; > +return 0 but True; > } > > Properties are predeclared as roles and implemented as mixins--see S12. > Is "but false" now spelled "but False"? If not, if there a reason for the asymmetry? -- Elyse M. Grasso CTO ReleaseTEAM Inc. http://www.releaseteam.com phone 720-887-0489 fax 720-977-8010 cell 303-356-2717
Re: A rule by any other name...
Patrick R. Michaud wrote: >> - is a single character of obligatory whitespace Hmm, it's literal ' ' (that is, \x20), not "whitespace" in general, right? For "obligatory whitespace" we have \s. > This one has bugged me since the day I first saw it implemented > in PGE. We _already_ have \s, , and to represent > the notion of "a whitespace character" -- do we really need a > separate form also? (An idle thought: perhaps "sp" is > better used as an :sp adverb and a corresponding regex?) Well, without // to stand for /\x20/, it'd have to be written as /<' '>/, which is a bit suboptimal. Or as /\ /, which is even more suboptimal... Audrey signature.asc Description: OpenPGP digital signature
Re: [perl #39044] Problem with :slurpy, :slurpy :named, :flat :named
Patrick R.Michaud (via RT) wrote: Currently Parrot has a variety of troubles with :slurpy and :slurpy :named both appearing in parameter lists. In particular, given a function such as .sub foo .param pmc array :slurpy .param pmc hash :slurpy :named Fixed. Thanks for the test. eo
Re: [perl #39045] [BUG] "isa" opcode doesn't (yet) work with keyed classnames
Patrick R.Michaud (via RT) wrote: $I0 = isa $P0, [ 'Perl6'; 'PAST'; 'Node'] Implemented in r12615. Thanks for the test. leo
Re: A rule by any other name...
On Thu, May 11, 2006 at 08:57:53PM +0800, Audrey Tang wrote: > Patrick R. Michaud wrote: > >> - is a single character of obligatory whitespace > > Hmm, it's literal ' ' (that is, \x20), not "whitespace" in general, > right? For "obligatory whitespace" we have \s. Oops, you're correct, I forgot that is already \x20. Allison's proposed definition of above seems to want to change that to "obligatory whitespace". That's more of what I was reacting against. For summary, here's how I currently read S05's space/whitespace rules (and what PGE implements, or is expected to implement): space character: \x20 \o40 <' '><[ ]> <+[ ]> backslash+space whitespace: \s > > We _already_ have \s, , and to represent > > the notion of "a whitespace character" -- do we really need a > > separate form also? (An idle thought: perhaps "sp" is > > better used as an :sp adverb and a corresponding regex?) > > Well, without // to stand for /\x20/, it'd have to be written as > /<' '>/, which is a bit suboptimal. [...] I agree, makes more sense as \x20, so I retract my idle thought. Thanks, Pm
Re: A rule by any other name...
On Wed, May 10, 2006 at 05:58:57PM -0700, Allison Randal wrote: > rule: > - Has :ratchet and :skip turned on by default > > - May only be used inside a grammar Should that be - Must be declared as part of a grammar or role ??? The verb "used" doesn't make much sense to me there. I use a rule when I'm applying it as a pattern to a string. The situation where rules can be defined anywhere but must only be used in a grammar doesn't make sense to me, so I assume that you meant that "rules must belong to a grammar". (btw, I also assumed that "may only" really meant "must") And if we're keeping the correspondence between classes+methods and grammars+rules, then surely grammars are composable entities just like classes. Seeking clarification, -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: A rule by any other name...
> >Including :skip(//). Yes, agreed, it's a huge > >improvement. I'd be more comfortable if the default rule to use for > >skipping was named instead of . (On IRC was also > >proposed, but the connection between :skip and is more > >immediately obvious.) > Yes, I like too. I too keep mistakely reading as > "WhiteSpace". For another datapoint, I like the idea of "" as word-boundary. After all, when you're tokenizing input, you're interested in the boundaries that separate tokens rather than the whitespace or what you do with it. Although I like the connection between and :skip, to me isn't very suggestive, and sounds too much like whitespace. , to me at least, is reminiscent of \b, and of Vim's \< \> for word boundaries. I'm sure I'll get used to whatever the final name is, though; just wanted to spread ideas. There are, to my mind, two ways of looking at whitespace: 1) Whitespace in regexes is ignored other than to delineate tokens in the regex. :skip() defines which characters in the input string are skipped over by the matcher (regex engine, whatever you want to call it). 2) Whitespace in regexes is significant. :skip() defines the meaning of a block of whitespace in the regular expression. AFAICS, both these states of mind come out to the same thing in the end (someone correct me if I'm wrong), but the naming scheme makes much more sense if you are thinking about it the first way. -- "For God's sake, please give it up. Fear it no less than the sensual passion, because it, too, may take up all your time and deprive you of your health, peace of mind and happiness in life." Wolfgang Bolyai, urging his son to give up his research on non-Euclidean geometry signature.asc Description: Digital signature
Re: A rule by any other name...
Audrey Tang wrote: > Patrick R. Michaud wrote: >> - is a single character of obligatory whitespace > > Hmm, it's literal ' ' (that is, \x20), not "whitespace" in > general, right? For "obligatory whitespace" we have \s. Are all or some of the following equivalent to ? U+00A0 No-Break Space U+202F Narow No-Break Space U+FEFF Zero Width No-Break Space U+2060 Word Joiner Many more here, like the Nut and the Mutton: http://en.wikipedia.org/wiki/Space_character (with nice links) -- Groet, Ruud
Re: A rule by any other name...
Ruud H.G. van Tol wrote: > Are all or some of the following equivalent to ? > > U+00A0 No-Break Space > U+202F Narow No-Break Space > U+FEFF Zero Width No-Break Space > U+2060 Word Joiner No. A05 makes it explicit is just \x20, and S05 also says that it matches one "space char", which also means U+0020 SPACE, although more vaguely. I think S05 can use this clarification diff: - / /# match a space char + / /# match the SPACE character (U+0020) Thanks, Audrey signature.asc Description: OpenPGP digital signature
[svn:perl6-synopsis] r9197 - doc/trunk/design/syn
Author: larry
Date: Thu May 11 09:55:36 2006
New Revision: 9197
Modified:
doc/trunk/design/syn/S05.pod
Log:
Changed :words/:w to :sigspace/:s and invented ss/// and ms// (or maybe mm//).
Modified: doc/trunk/design/syn/S05.pod
==
--- doc/trunk/design/syn/S05.pod(original)
+++ doc/trunk/design/syn/S05.podThu May 11 09:55:36 2006
@@ -14,9 +14,9 @@
Maintainer: Patrick Michaud <[EMAIL PROTECTED]> and
Larry Wall <[EMAIL PROTECTED]>
Date: 24 Jun 2002
- Last Modified: 24 Apr 2006
+ Last Modified: 11 May 2006
Number: 5
- Version: 23
+ Version: 24
This document summarizes Apocalypse 5, which is about the new regex
syntax. We now try to call them I because they haven't been
@@ -151,10 +151,13 @@
=item *
-The new C<:w> (C<:words>) modifier causes whitespace sequences to be
-replaced by C<\s*> or C<\s+> subpattern as defined by the C<< >> rule.
+The new C<:s> (C<:sigspace>) modifier causes whitespace sequences
+to be considered "significant". That is, they are replaced by a
+whitespace matching rule, C<< >>.
- m:w/ next cmd = /
+Anyway,
+
+ m:s/ next cmd = /
Same as:
@@ -166,17 +169,43 @@
But in the case of
- m:w { (a|\*) (b|\+) }
+ m:s {(a|\*) (b|\+)}
or equivalently,
m { (a|\*) (b|\+) }
-C<< >> can't decide what to do until it sees the data. It still does
-the right thing. If not, define your own C<< >> and C<:w> will use that.
+C<< >> can't decide what to do until it sees the data.
+It still does the right thing. If not, define your own C<< >>
+and C<:sigspace> will use that.
-In general you don't need to use C<:w> within grammars because
+In general you don't need to use C<:sigspace> within grammars because
the parser rules automatically handle whitespace policy for you.
+In this context, whitespace often includes comments, depending on
+how the grammar chooses to define its whitespace rule. Although the
+default C<< >> subrule recognizes no comment construct, any
+grammar is free to override the rule. The C<< >> rule is not
+intended to mean the same thing everywhere.
+
+It's also possible to pass an argument to C<:sigspace> specifying
+a completely different subrule to apply. This can be any rule, it
+doesn't have to match whitespace. When discussing this modifier, it is
+important to distinguish the significant whitespace in the pattern from
+the "whitespace" being matched, so we'll call the pattern's whitespace
+I, and generally reserve I to indicate whatever
+C<< >> matches in the current grammar. The correspondence
+between sigspace and whitespace is primarily metaphorical, which is
+why the correspondence is both useful and (potentially) confusing.
+
+The C<:s> modifier is considered sufficiently important that
+match variants are defined for them:
+
+ms/match some words/ # same as m:sigspace
+ss/match some words/replace those words/ # same ss s:sigspace
+
+Conjecture: This might become sufficiently idiomatic that C would
+be better as a "stuttered" C instead, much as C became idiomatic.
+It would also match C that way.
=item *
@@ -311,10 +340,10 @@
=item *
-The C<:i>, C<:w>, C<:Perl5>, and Unicode-level modifiers can be
+The C<:i>, C<:s>, C<:Perl5>, and Unicode-level modifiers can be
placed inside the regex (and are lexically scoped):
- m/:w alignment = [:i left|right|cent[er|re]] /
+ m/:s alignment = [:i left|right|cent[er|re]] /
=item *
@@ -389,7 +418,7 @@
=item *
Whitespace is now always metasyntactic, i.e. used only for layout
-and not matched literally (but see the C<:w> modifier described above).
+and not matched literally (but see the C<:sigspace> modifier described above).
=back
@@ -604,8 +633,8 @@
/ /# was /(?=pattern)/
/ / # was /(? /# match whitespace by :w policy
- / /# match a space char
+ / /# match whitespace by :s policy
+ / /# match the SPACE character (U+0020)
/ / # match only at a particular StrPos
# short for
@@ -966,8 +995,8 @@
If either form needs modifiers, they go before the opening delimiter:
- $regex = regex :g:w:i { my name is (.*) };
- $regex = rx:g:w:i / my name is (.*) /;# same thing
+ $regex = regex :g:s:i { my name is (.*) };
+ $regex = rx:g:s:i / my name is (.*) /;# same thing
Space is necessary after the final modifier if you use any
bracketing character for the delimiter. (Otherwise it would be taken as
@@ -978,7 +1007,7 @@
You may not use colons for the delimiter. Space is allowed between
modifiers:
- $regex = rx :g :w :i / my name is (.*) /;
+ $regex = rx :g :s :i / my name is (.*) /;
=item *
@@ -1072,10 +1101,10 @@
The other is the C declarator, for declaring non-terminal
productions in a
Provisional Foo [Was: [svn:perl6-synopsis] r9176 - doc/trunk/design/syn]
On Thu, May 11, 2006 at 07:44:54AM -0400, Elyse M. Grasso wrote:
: Is "but false" now spelled "but False"? If not, if there a reason for the
: asymmetry?
Yes, the false value is False now, just as the true value is not True.
The reason for changing them is to avoid confusion with the built-in
true() function, and the theoretical false() function, which is
actually spelled "not".
The Bool type is an enum with values . As with any enum,
we also treat those names as subset types. Indeed, any constant can
function as a subset type. Constant functions are naturally 0-ary,
and in C culture tend to be uppercase anyway. So arguably, we could
have a rule or policy that 0-ary functions are generally uppercase,
not just the constant ones. Instead of time, we'd have Time.
Then the 0-or-1-ary functions could be rand(42) vs Rand, and the Rand
form would never look for an argument. Defining a
sub baz ($x?) {...}
would also define
sub Baz () {...}
Have to think about that some more, though. Could also say that,
unlike a provisional "foo", a provisional "Foo" would be considered
0-ary rather than list op. As with any provisional, a Foo would
have to resolve to a sub Foo () or a sub foo ($x?) by the end of
the compilation.
Hmm.
Larry
Re: S02: generalized quotes and adverbs
On Wed, May 10, 2006 at 08:09:45AM +0100, Daniel Hulme wrote: : > qX ::= "q:x:y:z"; : > : > as a simple, argumentless "word" macro. : But would that DWIM when I come to write : : qX(stuff, specifically not an adverb argument); : : ? Just looking at it, I would expect qX() to call a function. Knowing the macro, I'd expect it to do q :x :y :z() and then treat the ; as the delimiter, which probably means the macro should have been written: qX ::= "q:x:y:z "; and then the qX() form either does "q:x:y:z ()" or calls the qX() function. Which all probably means that we're still better off distinguishing quote macros from "word" macros so that the intent is clear. A quote macro would have no doubt: qX() always means to call the qX function, not the quoter. Larry
Re: Provisional Foo [Was: [svn:perl6-synopsis] r9176 - doc/trunk/design/syn]
On Thu, May 11, 2006 at 10:24:24AM -0700, Larry Wall wrote:
> function as a subset type. Constant functions are naturally 0-ary,
> and in C culture tend to be uppercase anyway. So arguably, we could
> have a rule or policy that 0-ary functions are generally uppercase,
> not just the constant ones. Instead of time, we'd have Time.
> Then the 0-or-1-ary functions could be rand(42) vs Rand, and the Rand
> form would never look for an argument. Defining a
I'm not convinced that this holds, as Rand isn't constant, whereas the C
uppercase convention applies to constants. Also, the C convention tends to
be all-caps, unless I've mis-understood which convention you're referring to.
> sub baz ($x?) {...}
>
> would also define
>
> sub Baz () {...}
>
> Have to think about that some more, though. Could also say that,
Presumably it's titlecase rather than uppercase.
This doesn't introduce any interesting ambiguities, does it?
IIRC the "fun" stuff involves lowercase and Greek letter sigma following
something, which therefore isn't relevant here.
Nicholas Clark
--
I'm looking for a job: http://www.ccl4.org/~nick/CV.html
Re: A rule by any other name...
Damian Conway wrote:
skip:
- We keep :words as shorthand for :skip(//)
- And :skip is shorthand for :skip(//)
...where defaults to , but is distinct from it (i.e. it can
be redefined independently).
It also has the benefit that developers redefining can call
as one of the alternates in their skip rule.
I'm tempted to make default to [\# \N*|], considering the
number of languages and non-languages that use that commenting form. It
provides a useful distinction between the default forms of :words and
:skip, and an intelligent default. But, there's potential for confusion
if someone is parsing say, a file of phone numbers each pre-pended with
"#". (Of course, it could be argued that if they really only want
whitespace skipped, they should use :words.)
- is optional whitespace,
Not quite. is semi-optional whitespace. More precisely, it's not
optional between two identifier characters:
token ws { \s+
| \s*
| \s*
}
Right, that's "skippy behavior".
> following skippy behavior (and it always behaves the same no matter
> what the current :skip pattern is)
Allison
Re: A rule by any other name...
Patrick R. Michaud wrote: On Thu, May 11, 2006 at 08:57:53PM +0800, Audrey Tang wrote: Patrick R. Michaud wrote: - is a single character of obligatory whitespace Hmm, it's literal ' ' (that is, \x20), not "whitespace" in general, right? For "obligatory whitespace" we have \s. Oops, you're correct, I forgot that is already \x20. Allison's proposed definition of above seems to want to change that to "obligatory whitespace". That's more of what I was reacting against. Read that line above as "all current abbreviations for various forms of obligatory whitespace remain the same". And I agree with Audrey that the S05 text needs to be clarified. Allison
Re: A rule by any other name...
Jonathan Scott Duff wrote: On Wed, May 10, 2006 at 05:58:57PM -0700, Allison Randal wrote: rule: - Has :ratchet and :skip turned on by default - May only be used inside a grammar Should that be - Must be declared as part of a grammar or role ??? It is: - The 'rule' keyword may only be used inside a grammar And if we're keeping the correspondence between classes+methods and grammars+rules, then surely grammars are composable entities just like classes. The distinction between inheritance and composition isn't as significant for grammars as it is for classes, since you can create a Match object instance from a single rule isolation. Allison
Re: A rule by any other name...
Patrick R. Michaud wrote: Whitespace in regexes and rules is metasyntactic, in that it is not matched literally. Effectively what the :w (or :words or :skip) option does it to change the metasyntactic meaning of any whitespace found in the regex. Or, another way of thinking of it -- as S05 currently stands, 'regex' and 'token' cause the pattern whitespace to be treated as , while 'rule' causes the pattern whitespace to become . So what we're really doing with this option--whatever we call it--is to specify what the whitespace _in the pattern_ should match. Somehow ":skip" and don't carry that meaning for me. In some sense it seems to me that the correct adverb is more along the lines of :ws, :white, or :whitespace, in that it says what to do with the whitespace in the pattern. It doesn't have to say anything about whether the pattern's whitespace is actually matching \s* (although the default rule for :ws/:white/:whitespace could certainly provide that semantic). I can fully see the argument that people will still confuse :ws and with "whitespace in the target", when in reality they specify the meaning of whitespace in the regex pattern, so :ws might not be the right choice for the adverb. But I think that something more closely meaning "whitespace in the pattern means /this/" would be a better adverb than :skip. Technically, true. But understanding that requires a deep understanding of what's happening in the grammar. With 'skip' all the average user needs to understand is "I'm telling the grammar to ignore these things". As a side note, trying to talk about both whitespace as literal thing that is matched and whitespace as a metasyntactic thing that is ignored requires a great deal of circumlocution, which is often a good trigger for language change to use a different word for one thing or the other. Allison
Re: A rule by any other name...
On Thu, May 11, 2006 at 12:19:21PM -0700, Allison Randal wrote:
> Jonathan Scott Duff wrote:
> >On Wed, May 10, 2006 at 05:58:57PM -0700, Allison Randal wrote:
> >>rule:
> >>- Has :ratchet and :skip turned on by default
> >>
> >>- May only be used inside a grammar
> >
> >Should that be
> >
> >- Must be declared as part of a grammar or role
> >
> >???
>
> It is:
>
> - The 'rule' keyword may only be used inside a grammar
So, just to be clear, does that mean that the following holds:
# assume no surrounding grammar-context
rule foo { ... } # compile-time error, no grammar
my $ar = rule { ... } # compile-time error, no grammar
grammar Foo;
rule bar { ... } # legal, Foo::bar rule
my $ar = rule { ... } # legal, Foo::ANON rule
# assume no surrounding grammar-context
rule Foo::bar { ... } # legal, Foo::bar rule
my $ar = grammar Foo { rule { ... } } # legal, Foo::ANON rule
And the way to get a grammarless rule is to use either rx or regex with
the appropriate modifiers.
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
[svn:perl6-synopsis] r9202 - doc/trunk/design/syn
Author: larry
Date: Thu May 11 13:33:29 2006
New Revision: 9202
Modified:
doc/trunk/design/syn/S03.pod
Log:
Various clarifications from jerry++ and others
Extra dot is now allowed before hyper postfix since whitespace disallowed there
Modified: doc/trunk/design/syn/S03.pod
==
--- doc/trunk/design/syn/S03.pod(original)
+++ doc/trunk/design/syn/S03.podThu May 11 13:33:29 2006
@@ -12,9 +12,9 @@
Maintainer: Larry Wall <[EMAIL PROTECTED]>
Date: 8 Mar 2004
- Last Modified: 9 May 2006
+ Last Modified: 11 May 2006
Number: 3
- Version: 27
+ Version: 28
=head1 Changes to existing operators
@@ -28,6 +28,10 @@
=item * The string concatenation C<.> becomes C<~>. Think of it as
"stitching" the two ends of its arguments together.
+=item * All postfix operators that do not start with a dot also have
+an alternate form that does. (The converse does not hold--just because
+you can write C doesn't mean you can write C.)
+
=item * Unary C<~> now imposes a string (C) context on its argument, and
C<+> imposes a numeric (C) context (as opposed to being a no-op in Perl
5). Along the same lines, C imposes a boolean (C) context, and C<*>
@@ -300,7 +304,10 @@
"list operations", which operate on each element of two lists (or
arrays) and return a list (or array) of the results. Spaces are not
allowed on the "pointy" end of each "hyper", but are allowed on the
-blunt end. For example:
+blunt end (except for postfix operators, which must still follow postfix
+spacing rules, but do for allow an additional dot before the "hyper").
+
+For example:
(1,1,2,3,5) »+« (1,2,3,5,8); # (2,3,5,8,13)
@@ -312,10 +319,15 @@
@negatives = -« @positives;
- @positions »++;# Increment all positions
+ @positions»++;# Increment all positions
- @objects ».run();
- ("f","oo","bar")».chars; # (1,2,3)
+ @positions.»++; # Same thing, dot form
+ @positions».++; # Same thing, dot form
+ @positions.».++; # Same thing, dot form
+ @positions\ .»\ .++;# Same thing, long dot form
+
+ @objects.».run();
+ ("f","oo","bar").>>.chars; # (1,2,3)
Note that method calls are really postfix operators, not infix, so you
shouldn't put a C<«> after the dot.
@@ -344,6 +356,9 @@
my @a = (5,6);
[*] @a; # 5 * 6 = 30
+As with the all metaoperators, space is not allowed inside. The whole
+thing parses as a single token.
+
A reduction operator really is a list operator, and is invoked as one.
Hence, you maybe implement a reduction operator in one of two ways. Either
you can write an explicit list operator:
@@ -403,8 +418,8 @@
However, the zero argument case must of necessity be handled by the
proto version, since there is no type information to dispatch on.
Operators that wish to specify an identity value should do so by
-specifying the proto listop. Among the builtin operators, [+]()
-returns 0 and [*]() returns 1, for instance.
+specifying the proto listop. Among the builtin operators, C<[+]()>
+returns 0 and C<[*]()> returns 1, for instance.
By default, if there is one argument, the built-in reduce operators
return that one argument. However, this default doesn't make sense
@@ -876,7 +891,7 @@
Perl 6 has 22 precedence levels (which is fewer than Perl 5):
terms 42 "eek" $x /abc/ (1+2) a(1) :by(2) .meth listop
-method postfix . .+ .? .* .() .[] .{} .«» .=
+method postfix . .+ .? .* .() .[] .{} .:: .«» .=
autoincrement ++ --
exponentiation **
symbolic unary ! + - ~ ? $ @ % & * ** +^ ~^ ?^ \ ^ =
@@ -890,7 +905,7 @@
tight and &&
tight or|| ^^ //
ternary ?? !!
-assignment = := ::= += -= **= xx= etc. (and also =>)
+assignment = := ::= += -= **= xx= .= etc. (and also =>)
list item separator , ¥
list op (rightward) <== print push any all true not etc. and ()= rightward
pipe forward==>
Re: [svn:perl6-synopsis] r9202 - doc/trunk/design/syn
[EMAIL PROTECTED] schreef: > Unary C<~> now imposes a string (C) context on its > argument, and C<+> imposes a numeric (C) context (as opposed to > being a no-op in Perl 5). Shouldn't unary minus be mentioned too? Or would one need C<0-> or C<-+>? > A reduction operator really is a list operator, and is invoked as > one. Hence, you maybe implement a reduction operator in one of two > ways. s/maybe/may|can/ ? > By default, if there is one argument, the built-in reduce operators > return that one argument. However, this default doesn't make sense ;) -- Groet, Ruud
Re: A rule by any other name...
Oh, and since we're calling them "regexes", I suggest calling them "regular expressions" too, since both "regex(p)" and "regular expression" have taken on the popular meaning of "pattern matching". If we're going to be anti-pedantic, let's be consistently anti-pedantic. :) Allison
Re: A rule by any other name...
On Thu, May 11, 2006 at 01:55:37PM -0700, Allison Randal wrote: : Oh, and since we're calling them "regexes", I suggest calling them : "regular expressions" too, since both "regex(p)" and "regular : expression" have taken on the popular meaning of "pattern matching". If : we're going to be anti-pedantic, let's be consistently anti-pedantic. :) Consistency is the hobgoblin of small languages. Larry
Re: [svn:perl6-synopsis] r9197 - doc/trunk/design/syn
[EMAIL PROTECTED] wrote: Log: Changed :words/:w to :sigspace/:s and invented ss/// and ms// (or maybe mm//). I keep expecting 'sigspace' to have something to do signatures. Larry++ on :s. :) Allison
Re: [svn:perl6-synopsis] r9197 - doc/trunk/design/syn
On Thu, May 11, 2006 at 02:15:58PM -0700, Allison Randal wrote: > [EMAIL PROTECTED] wrote: > > > >Log: > >Changed :words/:w to :sigspace/:s and invented ss/// and ms// (or maybe > >mm//). > > I keep expecting 'sigspace' to have something to do signatures. I keep thinking that 'sigspace' is the signal that agoraphobic processes least want to handle. But I guess really that should be written 'SIGSPACE' Nicholas Clark -- I'm looking for a job: http://www.ccl4.org/~nick/CV.html
Re: Provisional Foo [Was: [svn:perl6-synopsis] r9176 - doc/trunk/design/syn]
Larry Wall writes:
> Yes, the false value is False now, just as the true value is not True.
It's not? I thought somebody had just said that it was?
> The reason for changing them is to avoid confusion with the built-in
> true() function,
Makes sense.
> So arguably, we could have a rule or policy that 0-ary functions are
> generally uppercase, not just the constant ones. Instead of time,
> we'd have Time.
Does that actually gain us anything?
> Then the 0-or-1-ary functions could be rand(42) vs Rand, and the Rand
> form would never look for an argument.
Personally I think that'd be more confusing. It isn't particularly
intuitive, and it makes switching from one form to another more awkward
cos you don't just have to change the params after the function name but
also the case of the letter at the start.
And what about functions with names starting with an underscore?
> Defining a
>
> sub baz ($x?) {...}
>
> would also define
>
> sub Baz () {...}
>
> Could also say that, unlike a provisional "foo", a provisional "Foo"
> would be considered 0-ary rather than list op.
Who would benefit from this? To me it just seems like more complexity,
and encouraging hard-to-spot typos as we have things which differ only
in case. Surely if somebody has a function call C which they
explicitly want to mark as being 0-ary then writing it as C<(baz)> or
C is already a sufficiently convenient way of doing this, and is
intuitive to the casual reader.
I think the effort in learning this special case outweighs any benefit
it brings.
Smylers
Re: [svn:perl6-synopsis] r9197 - doc/trunk/design/syn
Allison Randal writes: > [EMAIL PROTECTED] wrote: > > > Log: > > Changed :words/:w to :sigspace/:s and invented ss/// and ms// (or > > maybe mm//). > > I keep expecting 'sigspace' to have something to do signatures. So do I. How about :litspace for 'literal space'? Except they aren't exactly literal, because they only indicate where _some_ space has to be, not that it has to be exactly that sort of space. What about :gappy, to indicate that there have to be gaps in the source text at the points where there are gaps in the pattern? Smylers
pirtidy - call for help
There is a start at a pirtidy perl script at tools/utils/pirtidy.pl, using lib/Parrot/PIR/Formatter.pm, tests at t/perl/ Parrot_PIR_Formatter.t There are a bunch of skip'd tests, some notes in the perl module listing some more possible things to be done. This mainly requires perl knowledge, with some understanding of PIR syntax. I have a few other things on my plate and probably won't get back to this soon. Regards.
[perl #39132] [TODO] pirtidy - call for help
# New Ticket Created by jerry gay # Please include the string: [perl #39132] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/rt3/Ticket/Display.html?id=39132 > forwarded to parrotbug to create a TODO ticket -- Forwarded message -- From: Will Coleda <[EMAIL PROTECTED]> Date: May 11, 2006 3:31 PM Subject: pirtidy - call for help To: Perl6 Internals There is a start at a pirtidy perl script at tools/utils/pirtidy.pl, using lib/Parrot/PIR/Formatter.pm, tests at t/perl/ Parrot_PIR_Formatter.t There are a bunch of skip'd tests, some notes in the perl module listing some more possible things to be done. This mainly requires perl knowledge, with some understanding of PIR syntax. I have a few other things on my plate and probably won't get back to this soon. Regards.
Re: [svn:perl6-synopsis] r9197 - doc/trunk/design/syn
Smylers wrote: Allison Randal writes: I keep expecting 'sigspace' to have something to do signatures. So do I. How about :litspace for 'literal space'? Except they aren't exactly literal, because they only indicate where _some_ space has to be, not that it has to be exactly that sort of space. What about :gappy, to indicate that there have to be gaps in the source text at the points where there are gaps in the pattern? Or, to borrow a word from a different artistic pursuit, 'negative space'. "Negative space is the space between objects or parts of an object, or around it." http://painting.about.com/library/weekly/aanegativespace.htm Or, perhaps contextualize the concept to computers as "nullspace". Allison
[svn:perl6-synopsis] r9204 - doc/trunk/design/syn
Author: larry
Date: Thu May 11 15:39:08 2006
New Revision: 9204
Modified:
doc/trunk/design/syn/S03.pod
doc/trunk/design/syn/S05.pod
doc/trunk/design/syn/S09.pod
Log:
Typos.
Tightened up prefix:<*> to match only before sigils and brackets,
so that *foo now always means GLOBAL::foo, and 0..*:by(2) works.
Modified: doc/trunk/design/syn/S03.pod
==
--- doc/trunk/design/syn/S03.pod(original)
+++ doc/trunk/design/syn/S03.podThu May 11 15:39:08 2006
@@ -14,7 +14,7 @@
Date: 8 Mar 2004
Last Modified: 11 May 2006
Number: 3
- Version: 28
+ Version: 29
=head1 Changes to existing operators
@@ -360,7 +360,7 @@
thing parses as a single token.
A reduction operator really is a list operator, and is invoked as one.
-Hence, you maybe implement a reduction operator in one of two ways. Either
+Hence, you can implement a reduction operator in one of two ways. Either
you can write an explicit list operator:
proto prefix:<[+]> ([EMAIL PROTECTED]) {
@@ -674,7 +674,7 @@
Since typeglobs are being removed, unary C<*> may now serve as an
interpolator, by casting its single operand to a C object
-and insert it into the current argument list.
+and inserting it into the current argument list.
It can be used to interpolate an C or C into the current
call, as positional and named arguments respectively.
@@ -737,6 +737,26 @@
You may use either of them on a scalar iterator to force it to iterate.
+The C<*> operator is recognized only if the next character is a sigil
+or an opening bracket, In front of an alphabetic character C<*> will
+always be taken to mean C. Otherwise it will be assumed
+the C<*> has no argument. See next section.
+
+To interpolate a function's return value, therefore, you must say one
+of these:
+
+push *(func())
+push *[func()]
+push *&func()
+
+because
+
+push *func()
+
+means
+
+push GLOBAL::func()
+
=item * The "Whatever" operator
If the C<*> prefix operator has I argument, it captures the notion
@@ -891,7 +911,7 @@
Perl 6 has 22 precedence levels (which is fewer than Perl 5):
terms 42 "eek" $x /abc/ (1+2) a(1) :by(2) .meth listop
-method postfix . .+ .? .* .() .[] .{} .:: .«» .=
+method postfix . .+ .? .* .() .[] .{} .«» .:: .=
autoincrement ++ --
exponentiation **
symbolic unary ! + - ~ ? $ @ % & * ** +^ ~^ ?^ \ ^ =
Modified: doc/trunk/design/syn/S05.pod
==
--- doc/trunk/design/syn/S05.pod(original)
+++ doc/trunk/design/syn/S05.podThu May 11 15:39:08 2006
@@ -152,14 +152,12 @@
=item *
The new C<:s> (C<:sigspace>) modifier causes whitespace sequences
-to be considered "significant". That is, they are replaced by a
-whitespace matching rule, C<< >>.
-
-Anyway,
+to be considered "significant"; they are replaced by a whitespace
+matching rule, C<< >>. That is,
m:s/ next cmd = /
-Same as:
+is the same as:
m/ next cmd = /
Modified: doc/trunk/design/syn/S09.pod
==
--- doc/trunk/design/syn/S09.pod(original)
+++ doc/trunk/design/syn/S09.podThu May 11 15:39:08 2006
@@ -12,9 +12,9 @@
Maintainer: Larry Wall <[EMAIL PROTECTED]>
Date: 13 Sep 2004
- Last Modified: 21 Apr 2006
+ Last Modified: 11 May 2006
Number: 9
- Version: 9
+ Version: 10
=head1 Overview
@@ -308,7 +308,7 @@
just like scalars -- the main caveat is that you have to use
binding rather than assignment to set one without copying:
-@b := @a[0..(*):by(2)]
+@b := @a[0..*:by(2)]
With PDLs in particular, this might alias each of the individual
elements rather than the array as a whole. So modifications to @b
@@ -340,7 +340,7 @@
semicolon-separated list of slice specifiers, also known as a multislice.
A three-dimensional slice might look like this:
-@x[0..10; 1,0; 1..(*):by(2)]
+@x[0..10; 1,0; 1..*:by(2)]
It is up to the implementation of C<@x> to decide how aggressively
or lazily this subscript is evaluated, and whether the slice entails
@@ -412,9 +412,9 @@
@nums[$min..$max:by(3)]
@nums[$min..$max]
-@nums[$min..(*):by(3)]
-@nums[1..(*):by(2)]# the odds
-@nums[0..(*):by(2)]# the evens
+@nums[$min..*:by(3)]
+@nums[1..*:by(2)] # the odds
+@nums[0..*:by(2)] # the evens
That's all just the standard Perl 6 notation for ranges. Additional
syntactic relief is always available as long as it's predeclared
Re: [svn:perl6-synopsis] r9197 - doc/trunk/design/syn
Allison Randal schreef: > larry: >> Changed :words/:w to :sigspace/:s and invented ss/// and ms// (or >> maybe mm//). > > I keep expecting 'sigspace' to have something to do signatures. /me3, since it alliterates with sigsep. -- Groet, Ruud
Re: [svn:perl6-synopsis] r9197 - doc/trunk/design/syn
On Fri, May 12, 2006 at 01:50:59AM +0200, Ruud H.G. van Tol wrote: : Allison Randal schreef: : > larry: : : >> Changed :words/:w to :sigspace/:s and invented ss/// and ms// (or : >> maybe mm//). : > : > I keep expecting 'sigspace' to have something to do signatures. : : /me3, since it alliterates with sigsep. Maybe we should form a SIG to discuss it. Larry
[svn:perl6-synopsis] r9208 - doc/trunk/design/syn
Author: larry
Date: Thu May 11 23:26:34 2006
New Revision: 9208
Modified:
doc/trunk/design/syn/S02.pod
doc/trunk/design/syn/S03.pod
Log:
Cleanup from spinclad++.
Modified: doc/trunk/design/syn/S02.pod
==
--- doc/trunk/design/syn/S02.pod(original)
+++ doc/trunk/design/syn/S02.podThu May 11 23:26:34 2006
@@ -1741,9 +1741,6 @@
:shortkey
:fookey{ $^a <=> $^b }
-But note that C<..> is not a long dot because at least one internal space
-is required to differentiate from the range operator.
-
=item *
The double-underscore forms are going away:
Modified: doc/trunk/design/syn/S03.pod
==
--- doc/trunk/design/syn/S03.pod(original)
+++ doc/trunk/design/syn/S03.podThu May 11 23:26:34 2006
@@ -305,7 +305,7 @@
arrays) and return a list (or array) of the results. Spaces are not
allowed on the "pointy" end of each "hyper", but are allowed on the
blunt end (except for postfix operators, which must still follow postfix
-spacing rules, but do for allow an additional dot before the "hyper").
+spacing rules, but do allow for an additional dot before the "hyper").
For example:
