Re: [svn:perl6-synopsis] r13551 - doc/trunk/design/syn
On Tue, Jan 30, 2007 at 12:31:17PM -0800, [EMAIL PROTECTED] wrote: > Author: larry > Date: Tue Jan 30 12:31:16 2007 > New Revision: 13551 > > Modified: >doc/trunk/design/syn/S09.pod > > Log: > Braino spotted by TSa++ > > > Modified: doc/trunk/design/syn/S09.pod > == > --- doc/trunk/design/syn/S09.pod (original) > +++ doc/trunk/design/syn/S09.pod Tue Jan 30 12:31:16 2007 > @@ -786,7 +786,7 @@ > When you use C<*> with C<+> and C<->, it creates a value of C > but C, which the array subscript interpreter will interpret as the > subscript one off the end of that dimension of the array. The lower > -right corner of a two dimesional array is C<@array[*-1, *-1]>. > +right corner of a two dimesional array is C<@array[*-1; *-1]>. And a typo "dimesional" should be "dimensional". Bob -- Mark's Dental-Chair Discovery: Dentists are incapable of asking questions that require a simple yes or no answer. signature.asc Description: Digital signature
[svn:perl6-synopsis] r13570 - doc/trunk/design/syn
Author: larry
Date: Mon Feb 5 14:26:23 2007
New Revision: 13570
Modified:
doc/trunk/design/syn/S03.pod
doc/trunk/design/syn/S05.pod
Log:
categories now allow multiple dispatch via longest-token rule
added : syntax to rules and tokens
seems a bit odd to call list-associative operators "binary"
Modified: doc/trunk/design/syn/S03.pod
==
--- doc/trunk/design/syn/S03.pod(original)
+++ doc/trunk/design/syn/S03.podMon Feb 5 14:26:23 2007
@@ -38,8 +38,8 @@
Junctive and (all) &
Junctive or (any) | ^
Named unary rand sleep abs
-Nonchaining binary but does <=> leg cmp .. ..^ ^.. ^..^ ff fff
-Chaining binary != == < <= > >= eq ne lt le gt ge ~~ === eqv !eqv
+Nonchaining infix but does <=> leg cmp .. ..^ ^.. ^..^ ff fff
+Chaining infix != == < <= > >= eq ne lt le gt ge ~~ === eqv !eqv
Tight and &&
Tight or|| ^^ // min max
Conditional ?? !!
Modified: doc/trunk/design/syn/S05.pod
==
--- doc/trunk/design/syn/S05.pod(original)
+++ doc/trunk/design/syn/S05.podMon Feb 5 14:26:23 2007
@@ -14,9 +14,9 @@
Maintainer: Patrick Michaud <[EMAIL PROTECTED]> and
Larry Wall <[EMAIL PROTECTED]>
Date: 24 Jun 2002
- Last Modified: 31 Jan 2007
+ Last Modified: 5 Feb 2007
Number: 5
- Version: 49
+ Version: 50
This document summarizes Apocalypse 5, which is about the new regex
syntax. We now try to call them I rather than "regular
@@ -395,6 +395,23 @@
m/:foo{xxx}/Parses as :foo {xxx}
m/:foo/Parses as :foo
+If the key of the pair is null, however, it is treated as a "symbol"
+declaration:
+
+:<*>Match * symbol
+:<[> :<]>Match bracketed expression as symbol :<[ ]>
+:['<','>'] Match empty <> as circumfix symbol
+:(&infix) Match any symbol matched by the infix category
+
+The components of a symbol declaration are matched literally, but
+the list of such symbols is gathered up when the rule is parsed and
+returned as the C<.symbol> property of the rule. (The C<.category>
+property should also be available for such rules, since these
+properties are used to form the eventual user-visible name of the
+operator being parsed.)
+
+The C<:()> form is conjectured to be useful in generating hyperoperators.
+
=item *
User-defined modifiers will be possible:
@@ -653,6 +670,26 @@
=item *
+Alternatively, if you predeclare a category, you can write multiple
+rules for the same category, differentiated only by the symbol they
+match:
+
+category sigil;
+token sigil { :<$> }
+token sigil { :<@> }
+token sigil { :<@@> }
+token sigil { :<%> }
+token sigil { :<&> }
+token sigil { :<::> }
+
+This can be viewed as a form of multiple dispatch, except that it's
+based on longest-token matching rather than signature matcing. The
+advantage of writing it this way is that it's easy to add additional
+rules to the same category in a derived grammar. All of them will
+be matched in parallel when you try to match C<< // >>.
+
+=item *
+
An interpolated hash matches the longest possible token. The match
fails if no entry matches. (A C<""> key will match anywhere, provided
no longer key matches.)
Re: [svn:perl6-synopsis] r13570 - doc/trunk/design/syn
On Feb 5, 2007, at 17:26 , [EMAIL PROTECTED] wrote: +This can be viewed as a form of multiple dispatch, except that it's +based on longest-token matching rather than signature matcing. The "matcing"? -- brandon s. allbery[linux,solaris,freebsd,perl] [EMAIL PROTECTED] system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED] electrical and computer engineering, carnegie mellon universityKF8NH
[svn:perl6-synopsis] r13571 - doc/trunk/design/syn
Author: larry
Date: Mon Feb 5 14:41:04 2007
New Revision: 13571
Modified:
doc/trunk/design/syn/S05.pod
Log:
typo from albery_b++
Modified: doc/trunk/design/syn/S05.pod
==
--- doc/trunk/design/syn/S05.pod(original)
+++ doc/trunk/design/syn/S05.podMon Feb 5 14:41:04 2007
@@ -683,7 +683,7 @@
token sigil { :<::> }
This can be viewed as a form of multiple dispatch, except that it's
-based on longest-token matching rather than signature matcing. The
+based on longest-token matching rather than signature matching. The
advantage of writing it this way is that it's easy to add additional
rules to the same category in a derived grammar. All of them will
be matched in parallel when you try to match C<< // >>.
Re: [svn:perl6-synopsis] r13571 - doc/trunk/design/syn
On Mon, Feb 05, 2007 at 02:41:06PM -0800, [EMAIL PROTECTED] wrote: : typo from albery_b++ Figured I'd start in on all the possible misspellings now... O_o Larry
[svn:perl6-synopsis] r13572 - doc/trunk/design/syn
Author: larry Date: Mon Feb 5 15:07:01 2007 New Revision: 13572 Modified: doc/trunk/design/syn/S03.pod Log: $obj.Foo::bar is also okay syntax if Foo declared Modified: doc/trunk/design/syn/S03.pod == --- doc/trunk/design/syn/S03.pod(original) +++ doc/trunk/design/syn/S03.podMon Feb 5 15:07:01 2007 @@ -12,9 +12,9 @@ Maintainer: Larry Wall <[EMAIL PROTECTED]> Date: 8 Mar 2004 - Last Modified: 3 Feb 2007 + Last Modified: 5 Feb 2007 Number: 3 - Version: 97 + Version: 99 =head1 Overview @@ -245,6 +245,7 @@ Class-qualified method call $obj.::Class::meth +$obj.Class::meth# same thing, assuming Class is predeclared =item *
Negative array subscripts
On 1/30/07, [EMAIL PROTECTED] wrote in "[svn:perl6-synopsis] r13549
- doc/trunk/design/syn":
+It has become the custom to use negative subscripts to indicate counting
+from the end of an array. This is still supported, but only for unshaped
+arrays:
+For shaped arrays you must explicitly refer to the current endpoint
+using C<*>, the C object:
Bringing us back to the discussion of ordinals from a few years ago...
On 9/6/04, Larry Wall wrote in "Re: Synopsis 9 draft 1":
Another possibility is that .[] always forces the "normal" view of
an array as 0-based, and if you want non-0-based arrays you have to
use the .{} interface instead, on the assumption that strange
subscripts
are more like hash keys than ranges of integers. Certainly if you
have a sparse array with keys like 1,2,4,8,16,32... you have a
situation that's more like a hash than an array. A sparse array
might not even give you the .[] interace. The presence of a .[]
interface might signal the ability to process contigous ranges, even
if those ranges are offset from the .{} range.
Such an approach would have the benefit that a module could simply
treat all its arrays as 0-based .[] arrays, and if you happened to
pass a non-0-based .{} array in, it would still work, albeit with
0-based indexes instead of whatever shape the .{} interface uses.
I don't think anything came of that, but the more I think about it,
the more I like it. Sparse/negative/etc. array indices really are
more like hash-keys than ordinals, so why don't we go ahead and have
two different ways to look up elements from arrays and hashes?
Also, this would solve a problem I've been wondering about with
"funny" shapes being lexically scoped. From S09:
You can pretend you're programming in Fortran, or awk:
my int @ints (1..4, 1..2); # two dimensions, @ints[1..4; 1..2]
Note that this only influences your view of the array in the current
lexical scope, not the actual shape of the array. If you pass this
array to another module, it will see it as having a shape of
(0..3,0..1) unless it also declares a variable to view it
differently.
However, what if you pass the funny array along with a (funny) index?
E.g. our @flavours (1..32);
my $favourite = get_fave(@flavours); #returns index of selected flavour
warn "Sorry, all out of @flavours[$favourite]!"
unless in_stock(@flavours, $favourite);
Which means that you'd be checking for the wrong thing to be in
stock. (Actually, you'd also get the wrong index back from
get_fave(), so in this limited example, the two errors would probably
cancel each other out, but the warning message will print the wrong
flavour because it's using the shifted index.)
Of course, thinking of arrays as numbered consecutively from 0 to n
will probably result in speaking P6 with a P5 accent: better to "for
[each]" over an array rather than loop across index numbers. If you
needed to use the index values, there was no alternative in P5 (or C,
etc.), but now we can use @foo.keys or .kv, and get the actual
indices even when the array is sparse, or uses negative subscripts.
But there will still be a need to traverse arrays ordinally, so I
think reserving [] lookups for this purpose is a good idea. Then
it's always clear whether you're using the "funny" (i.e. {}) keys or
the "old-fashioned" (i.e. []) ordinals. And negative subscripts can
always count backwards inside [] (and just be actual negative keys
inside {}).
Then we wouldn't need * to count backwards, although it's still
useful to allow us to count past the end of an array. There are all
sorts of variations on this scheme, such as whether * is the last
element or the one after that, etc., or whether 0 should be the first
element or the last, and so on.
(And of course, if arrays can be indexed with {}, then hashes can be
indexed with [] -- dunno if there's any point for ordinary hashes,
but it certainly could be useful with ordered ones.)
-David
Re: Negative array subscripts
On 2/5/07, David Green wrote: Then we wouldn't need * to count backwards, although it's still useful to allow us to count past the end of an array. There are all sorts of variations on this scheme, such as whether * is the last element or the one after that, etc., or whether 0 should be the first element or the last, and so on. In some ways, I like not having a [0] index at all: programmers may be used to counting from zero, but normal humans start with first, second, third, ... third last, second last, ["first"] last, so it would make sense to count: @[EMAIL PROTECTED], 2, 3, ..., -3, -2, -1] And then to count past the ends, something like: [..., -*-2, -*-1, -*, 1, 2, 3, ..., -3, -2, -1, +*, *+1, *2, ...] Or since * stands for everything, maybe that should be ..., *-2, *-1, * , *+1, *+2, ...? The thing I like best about this option is that it most clearly preserves the notion of "*" as "everything"; *-1 is the element before everything, and *+1 is the element after everything else. If there is a way to work "modulated" (cyclic/wrap-around) arrays into this, then we'd want to have a zero in there somewhere, although it still wouldn't have to be first; instead count first, second, third, ..., last but two, last but one, last: [1, 2, 3, ..., -2, -1, 0] (So, for a mod-4 array, @[EMAIL PROTECTED],2,3,[EMAIL PROTECTED],6,7,[EMAIL PROTECTED],-2,-1,0] etc.?) Yet another way (that avoids distinct +* and -*) is: [..., -2,-1] @foo[0, 1, 2, ..., *-2, *-1] [+*, *+1, *+2, ...] (or [..., -1, 0] @foo[1, 2, 3, ..., *-1, +*] [*+1, *+2, ...] or something.) Then *+/-n always refers to the end point, and we can count continuously across the front end of an array or the back. -David
