[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
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: - sp 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, blank, and space to represent the notion of a whitespace character -- do we really need a separate sp form also? (An idle thought: perhaps sp is better used as an :sp adverb and a corresponding ?sp regex?) Well, without /?sp/ 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: 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(/someotherrule/). Yes, agreed, it's a huge improvement. I'd be more comfortable if the default rule to use for skipping was named skip instead of ws. (On IRC sep was also proposed, but the connection between :skip and skip is more immediately obvious.) Yes, I like skip too. I too keep mistakely reading ws as WhiteSpace. For another datapoint, I like the idea of wb 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 skip and :skip, skip to me isn't very suggestive, and ws sounds too much like whitespace. wb, 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: - sp 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 sp? 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 sp? 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 sp 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: - / sp /# match a space char + / sp /# 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 Iregex 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 ?ws 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 ?ws .
- m:w/ next cmd = condition/
+Anyway,
+
+ m:s/ next cmd = condition/
Same as:
@@ -166,17 +169,43 @@
But in the case of
- m:w { (a|\*) (b|\+) }
+ m:s {(a|\*) (b|\+)}
or equivalently,
m { (a|\*) ?ws (b|\+) }
-C ?ws can't decide what to do until it sees the data. It still does
-the right thing. If not, define your own C ?ws and C:w will use that.
+C ?ws can't decide what to do until it sees the data.
+It still does the right thing. If not, define your own C ?ws
+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 ?ws subrule recognizes no comment construct, any
+grammar is free to override the rule. The C ?ws 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
+Isigspace, and generally reserve Iwhitespace to indicate whatever
+C ?ws 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 Cms// would
+be better as a stuttered Cmm// instead, much as Cqq// became idiomatic.
+It would also match Css/// 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 @@
/ before pattern /# was /(?=pattern)/
/ after pattern / # was /(?pattern)/
- / ws /# match whitespace by :w policy
- / sp /# match a space char
+ / ws /# match whitespace by :s policy
+ / sp /# match the SPACE character (U+0020)
/ at($pos) / # match only at a particular StrPos
# short for ?{ .pos == $pos }
@@ -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
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 False True. 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(/ws/)
- And :skip is shorthand for :skip(/skip/)
...where skip defaults to ws, but is distinct from it (i.e. it can
be redefined independently).
It also has the benefit that developers redefining skip can call ws
as one of the alternates in their skip rule.
I'm tempted to make skip default to [\# \N*|ws], 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.)
- ws is optional whitespace,
Not quite. ws is semi-optional whitespace. More precisely, it's not
optional between two identifier characters:
token ws { after \w \s+ before \w
| after \w \s* before \W
| after \W \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: - sp 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 sp is already \x20. Allison's proposed definition of sp 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 ?null, while 'rule' causes the pattern whitespace to become ?ws. 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 ?skip 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 ?ws 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 Cx().foo doesn't mean you can write Cx()foo.)
+
=item * Unary C~ now imposes a string (CStr) context on its argument, and
C+ imposes a numeric (CNum) context (as opposed to being a no-op in Perl
5). Along the same lines, C? imposes a boolean (CBool) 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 (CStr) context on its argument, and C+ imposes a numeric (CNum) context (as opposed to being a no-op in Perl 5). Shouldn't unary minus be mentioned too? Or would one need C0- 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 Cbaz which they
explicitly want to mark as being 0-ary then writing it as C(baz) or
Cbaz() 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
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 CCapture object
-and insert it into the current argument list.
+and inserting it into the current argument list.
It can be used to interpolate an CArray or CHash 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 CGLOBAL::. 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 Ino 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 ?ws .
-
-Anyway,
+to be considered significant; they are replaced by a whitespace
+matching rule, C ?ws . That is,
m:s/ next cmd = condition/
-Same as:
+is the same as:
m/ ?ws next ?ws cmd ?ws = ?ws condition/
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
