Re: [S09] Whatever indices and shaped arrays
OK: before I submit a patch, let me make sure that I've got the
concepts straight:
@x[0] always means the first element of the array; @x[-1] always
means the last element of the array; @x[*+0] always means the
first element after the end of the array; @x[*-1] always means the
first element before the beginning of the array. That is, the
indices go:
..., *-3, *-2, *-1, 0, 1, 2, ..., -3, -2, -1, *+0, *+1, *+2, ...
^ ^
| |
first last
As well, a Whatever in square braces is treated as an array of the
valid positions; so @x[*] is equivalent to @x[0..-1].
If you want to use sparse indices and/or indices that begin somewhere
other than zero, access them using curly braces. Consider an array
with valid indices ranging from -2 to +2: @x{-2} means element -2,
which would be equivalent to @x[0]; @x{+2} means element 2, which
would be equivalent to @x[-1]. Likewise, @x{0} is the same as @x[2],
@x{-3} is the same as @x[*-1], @x{+3} is the same as @x[*+0], and so
on. If @y has a series of five indices that start at 1 and double
with each step, then @y{1} will be the same as @y[0]; @y{4} will be
the same as @y[2], and so on.
A Whatever in curly braces is treated as an array of the valid index
names; so @x{*} means @x{-2..+2}, and @y{*} means @y{1, 2, 4, 8, 16}.
Because it is treated as an array, individual index names can be
accessed by position: @x{*[0]} is a rather verbose way of saying
@x[0]. This lets you embed ordinal indices into slices involving
named indices. Conversely, using *{...} inside square braces lets you
embed named indices into slices involving ordinal indices: @x[*{-2}]
is the same as @x{-2}.
Multidimensional arrays follow the above conventions for each of their
dimensions; so a single-splat provide a list of every index in a given
dimension, a 0 refers to the first index in that dimension, and so on.
A double-splat extends the concept to a multidimensional list that
handles an arbitrary number of dimensions at once.
--
Commentary: I find the sequence of ordinals outlined above to be a bit
messy, especially when you start using ranges of indices: you need to
make sure that @x[0..-1] dwims, that @x[-1..(*+0)] dwims, that
@x[(*-2)..(*+3)] dwims, and so on. This is a potentially very ugly
process. As well, the fact that @x[-1] doesn't refer to the element
immediately before @x[0] is awkward, as is the fact that @x[*-1]
doesn't refer to the element immediately before @x[*+0]. IMHO, it
would be cleaner to have @x[n] count forward and backward from the
front of the array, while @x[*+n] counts forward and backward from
just past the end of the array:
..., -3, -2, -1, 0, 1, 2, ..., *-3, *-2, *-1, *+0, *+1, *+2, ...
^^
||
first last
So perl 5's $x[-1] would always translate to @x[*-1] in perl 6.
Always. Likewise, @x[+*] would be the same as @x[*+0]. (In fact,
the semantics for @x[*+n] follows directly from the fact that an
array returns the count of its elements in scalar context.) And
@x[*] would be the same as @x[0..^*] or @x[0..(*-1)].
You would lose one thing: the ability to select an open-ended Range of
elements. For a five-element list, @x[1..^*] means @x[1, 2, 3,
4], not @x[1, 2, 3, 4, 5, 6, 7, 8, ...].
Technically, one could say @x{+*} to reference the index that
coincides with the number of indices; but it would only be useful in
specific cases, such as referencing the last element of a one-based
contiguous array.
--
Jonathan Dataweaver Lang
[svn:perl6-synopsis] r14314 - doc/trunk/design/syn
Author: audreyt
Date: Wed Mar 7 09:10:48 2007
New Revision: 14314
Modified:
doc/trunk/design/syn/S06.pod
Log:
* S06: Instead of introducing the conjectural concept of
single-semicolon delimited multiple-longnames, delegate
the discussion to S12 and present the non-controversial
double-semicolon form as the example instead.
Modified: doc/trunk/design/syn/S06.pod
==
--- doc/trunk/design/syn/S06.pod(original)
+++ doc/trunk/design/syn/S06.podWed Mar 7 09:10:48 2007
@@ -13,9 +13,9 @@
Maintainer: Larry Wall [EMAIL PROTECTED]
Date: 21 Mar 2003
- Last Modified: 28 Feb 2007
+ Last Modified: 8 Mar 2007
Number: 6
- Version: 73
+ Version: 74
This document summarizes Apocalypse 6, which covers subroutines and the
@@ -510,22 +510,24 @@
=head2 Longname parameters
-Much like ordinary methods give preference to the invocant,
-multimethods and multisubs can give preference to earlier parameters.
-These are called Ilongnames; see S12 for more about the semantics
-of multiple dispatch. Syntactically, longnames are declared by
-terminating the list of important parameters with a semicolon:
-
-multi sub handle_event ($window, $event; $mode) {...}
-multi method set_name ($self: $name; $nick) {...}
-
-A double semicolon terminates the longest possible longname; parameters
-after this are never considered for multiple dispatch (except of course
-that they can still veto if their number or types mismatch). (Note,
-the single semicolon form is still considered conjectural, though the
-double semicolon is fairly certain.)
+Routines marked with Cmulti can mark part of its parameters to
+be considered in the multi dispatch. These are called Ilongnames;
+see S12 for more about the semantics of multiple dispatch.
-If the parameter list for a Cmulti contains no semicolon to delimit
+You can choose part of a Cmulti's parameters to be its longname,
+by putting a double semicolon after the last one:
+
+multi sub handle_event ($window, $event;; $mode) {...}
+multi method set_name ($self: $name;; $nick) {...}
+
+A parameter list may have at most one double semicolon; parameters
+after it are never considered for multiple dispatch (except of course
+that they can still veto if their number or types mismatch).
+
+[Conjecture: It might be possible for a routine to advertise multiple
+long names, delimited by single semicolons. See S12 for details.]
+
+If the parameter list for a Cmulti contains no semicolons to delimit
the list of important parameters, then all positional parameters are
considered important. If it's a Cmulti method or Cmulti submethod,
an additional implicit unnamed Cself invocant is added to the
@@ -745,8 +747,8 @@
is required at least for its types, or the declaration would not know
what signature to match against.
-multi foo (|$args (Int; Bool?, *@, *%)) { reallyintfoo($args) }
-multi foo (|$args (Str; Bool?, *@, *%)) { reallystrfoo($args) }
+multi foo (|$args (Int, Bool?, *@, *%)) { reallyintfoo($args) }
+multi foo (|$args (Str, Bool?, *@, *%)) { reallystrfoo($args) }
=head2 Flattening argument lists
Re: request new Mapping|Hash operators
On February 27th Darren Duncan writes: At 4:45 PM + 2/27/07, Nicholas Clark wrote: 4. rename(): rename is a Perl 5 builtin. I see this situation as being similar to Dog.bark() vs Tree.bark(); The difference is that those are methods. Having different objects which have identically named methods is very different from having a built-in function which performs multiple, but very different, tasks based on its arguments. One common usage scenario, of relational-join in particular, is doing operations on tabular data, where you want to know something that involves matching up columns in several tables. Snip excellent example I've seen lots of programs that do things like that. But by a long way it's far more common to have the data tables in a database and use SQL for the joining than for the data to be elsewhere, such that SQL can't be used and it has to be read into Perl data structures for doing the joining. DBI is a module, not a core part of the Perl language. I think it would be odd for Perl 6 to have core support for these operations when most users would use DBI instead. For people doing data processing that requires this functionality I don't see why loading a module would be too much of a burden. In conclusion, I consider functionality like relational-join to provide considerable conciseness to very common data processing operations Are there Cpan modules in existence for doing this kind of thing in Perl 5? Smylers
[svn:perl6-synopsis] r14315 - doc/trunk/design/syn
Author: larry Date: Wed Mar 7 16:18:15 2007 New Revision: 14315 Modified: doc/trunk/design/syn/S03.pod Log: made my Any $x; $x := [1,2,3] a little dwammy (do what audreyt++ means :) Modified: doc/trunk/design/syn/S03.pod == --- doc/trunk/design/syn/S03.pod(original) +++ doc/trunk/design/syn/S03.podWed Mar 7 16:18:15 2007 @@ -12,9 +12,9 @@ Maintainer: Larry Wall [EMAIL PROTECTED] Date: 8 Mar 2004 - Last Modified: 28 Feb 2007 + Last Modified: 7 Mar 2007 Number: 3 - Version: 103 + Version: 104 =head1 Overview @@ -1001,7 +1001,17 @@ true in the above example. The binding fails if the type of the variable being bound is sufficiently -inconsistent with the type of the current declaration. +inconsistent with the type of the current declaration. Strictly speaking, +any variation on + +my Any $x; +$x := [1,2,3]; + +should fail because the type being bound is not consistent with +CScalar of Any, but since the CAny type is not a real instantiable +type but a generic (non)constraint, and CScalar of Any is sort of +a double non-constraint similar to CAny, we treat this situation +specially as the equivalent of binding to a typeless variable. =item * @@ -1009,7 +1019,9 @@ ::= -This does the same as C:= except it does it at compile time. +This does the same as C:= except it does it at compile time. (This implies +that the expression on the right is also evaluated at compile time; it does +not bind a lazy thunk.) =item *
[svn:perl6-synopsis] r14316 - doc/trunk/design/syn
Author: larry
Date: Wed Mar 7 17:25:32 2007
New Revision: 14316
Modified:
doc/trunk/design/syn/S03.pod
Log:
Clarifications requested by TheDamian++
Defined ++ and -- in terms of .succ and .pred so I could write s[] = $0.succ
Modified: doc/trunk/design/syn/S03.pod
==
--- doc/trunk/design/syn/S03.pod(original)
+++ doc/trunk/design/syn/S03.podWed Mar 7 17:25:32 2007
@@ -312,12 +312,40 @@
say $x unless %seen{$x}++;
-Increment of a CStr (in a suitable container) works as in Perl 5.
-(Use a derived type or a lexical multi to change this.) Perl 6 also
-supports CStr decrement.
+Increment of a CStr (in a suitable container) works similarly to
+Perl 5 except that the final alphanumeric sequence in the string is
+incremented regardless of what comes before it. For its typical use
+of incrementing a filename, you don't have to worry about the path name, but
+you do still have to worry about the extension, so you probably want to say
+
+my $fh = open $filename++ ~ '.jpg';
+
+Alternately, you can increment a submatch:
+
+$filename ~~ s[^.* (\w+) \.\w+$] = $().succ;
+
+Perl 6 also supports CStr decrement.
+
+Increment and decrement are defined in terms of the C.succ and
+C.pred methods on the type of object in the CScalar container.
+More specifically,
+
+++$var
+--$var
+
+are equivalent to
+
+$var.=succ
+$var.=pred
+
+If the type does not support these methods, the corresponding increment
+or decrement operation will fail. (The optimizer is allowed to assume
+that the ordinary increment and decrement operations on integers will
+not be overridden.)
Increment of a CBool (in a suitable container) turns it true.
-Decrement turns it false. This is useful if your C%seen array is
+Decrement turns it false regardless of how many times it was
+previously incremented. This is useful if your C%seen array is
actually a CKeySet, in which case decrement actually deletes it
from the CKeySet.
@@ -872,9 +900,14 @@
||
-Returns the left argument if it's true, otherwise evaluates and
-returns the right argument. In list context forces a false return
-to mean C(). See Cor below for low-precedence version.
+Returns the left argument if it's true, otherwise evaluates and returns
+the right argument. It is specifically allowed to use a list or array
+both as a boolean and as a list value produced if the boolean is true:
+
+@a = @b || @c; # broken in Perl 5; works in Perl 6
+
+In list context this operator forces a false return to mean C().
+See Cor below for low-precedence version.
=item *
@@ -1810,7 +1843,7 @@
=item *
-A function predeclared as 0-ary is never considered list
+A function predeclared as 0-ary is never considered a list
operator, though it allows an optional set of empty parentheses.
Unlike functions and list operators with arguments (see above),
a 0-ary function does not require parentheses even if followed
@@ -2024,10 +2057,13 @@
a negative C:by causes the C.minmax method returns C(.to,.from)
instead. You may also use C.min and C.max to produce the individual
values of the C.minmax pair, but again note that they are reversed
-from C.from and C.to when the step is negative.
+from C.from and C.to when the step is negative. Since a reversed
+CRange changes its direction, it swaps its C.from and C.to but
+not its C.min and C.max.
Because CRange objects are lazy, they do not automatically generate
-a list. So smart matching against a CRange object smartmatches the
+a list. One result of this is that a reversed CRange object is still lazy.
+Another is that smart matching against a CRange object smartmatches the
endpoints in the domain of the object being matched, so fractional
numbers are Cnot truncated before comparison to integer ranges:
@@ -2208,13 +2244,13 @@
Hash Hash hash keys same set $_.keys === X.keys
Set Hash hash keys same set $_ === X.keys
Array Hash hash slice existenceX.contains(any @$_)
-Regex Hash hash key grep any($_.keys) === /X/
+Regex Hash hash key grep any(X.keys).match($_)
ScalarHash hash entry existenceX.contains($_)
Any Hash hash slice existenceX.contains(any @$_)
Str Regex string pattern match.match(X)
-Hash Regex hash key boolean grep .any.match(/X/)
-Array Regex array boolean grep.any.match(/X/)
+Hash Regex hash key boolean grep .any.match(X)
+Array Regex array boolean grep.any.match(X)
Any Regex pattern match .match(X)
Num Range in numeric rangeX.min = $_ = X.max (mod ^'s)
Re: [S09] Whatever indices and shaped arrays
On 3/7/07, Jonathan Lang wrote:
summary snipped
Looks good to me.
As well, the fact that @x[-1] doesn't refer to the element
immediately before @x[0] is awkward, as is the fact that @x[*-1]
doesn't refer to the element immediately before @x[*+0]. IMHO, it
would be cleaner to have @x[n] count forward and backward from the
front of the array, while @x[*+n] counts forward and backward from
just past the end of the array:
I suggested that at one point, so I'd agree that makes sense too. It
avoids the discontinuity at either end of the array -- although
arguably, points off the end of a list aren't in the same boat as
elements that actually exist, so the discontinuity might be
conceptually justified. (Make the weird things look weird?)
(In fact, the semantics for @x[*+n] follows directly from the fact
that an array returns the count of its elements in scalar context.)
And @x[*] would be the same as @x[0..^*] or @x[0..(*-1)].
That's an elegance in its favour.
One possible downside is that it wouldn't work for cyclic/wrap-around
arrays (where the indices are always interpreted mod n) -- since any
number would always refer to an existing element. Oh -- but if an
index isn't a plain counter, then it should be a named key, so scrap
that.
(The question then is: how to have reducible hash keys? By which I
mean different keys that get reduced to the same thing, e.g. %x{1}
=== %x{5} === %x{9} === %x{13}, etc. Presumably you can just
override the .{} method on your hash, right?)
You would lose one thing: the ability to select an open-ended Range
of elements. For a five-element list, @x[1..^*] means @x[1, 2,
3, 4], not @x[1, 2, 3, 4, 5, 6, 7, 8, ...].
Except wouldn't the .. interpret the * before the [] did? So 1..*
would yield a range-object from 1 to Inf, and then the array-deref
would interpret 1..Inf accordingly.
Actually, it seems more useful if the * could mean the count; you can
always say 1..Inf if that's what you want, but otherwise how would
you get [1..^*] meaning [1,2,3,4]? Perhaps the range could note when
it's occurring in []-context, and interpret the * as count rather
than as Inf?
-David
Whatevereversing Ranges
On 2/28/07, [EMAIL PROTECTED] wrote: Ranges are not autoreversing: C2..1 is always a null range. I assume the reason for not having ranges automatically go in either direction is that it would make it easier for subtle bugs to creep in when either end is smaller (or bigger) than you expected, and doing nothing is usually preferable to doing the wrong thing. Still, it would be useful to have a way to travel in whatever direction is the natural one... and the whatever term seems an obvious choice. So can :by(*) for a range mean go up or down according to whichever way makes sense? To iterate a range in reverse use: 2..1:by(-1) reverse 1..2 (The Creverse is preferred because it works for alphabetic ranges as well.) :by(*) is not only nicer than :by( ($a$b) ?? -1 !! +1), but it could presumably also increment or decrement suitably for the types involved. -David
[svn:perl6-synopsis] r14317 - doc/trunk/design/syn
Author: larry
Date: Wed Mar 7 20:38:15 2007
New Revision: 14317
Modified:
doc/trunk/design/syn/S02.pod
doc/trunk/design/syn/S11.pod
Log:
Module longnames now specified in terms of ident plus adverbials.
Modified: doc/trunk/design/syn/S02.pod
==
--- doc/trunk/design/syn/S02.pod(original)
+++ doc/trunk/design/syn/S02.podWed Mar 7 20:38:15 2007
@@ -2531,6 +2531,21 @@
END
}
+=item *
+
+A version literal are written with a 'v' followed by the version
+number in dotted form. This always constructs a CVersion object, not
+a string. Only integers are allowed; for anything fancier you must
+coerce a string to a CVersion:
+
+v1.2.3 # okay
+v1.2.3beta # illegal
+Version('1.2.3beta')# okay
+
+Note though that most places that take a version number in Perl accept
+it as a named argument, in which case saying C :ver1.2.3beta is fine.
+See S11 for more on using versioned modules.
+
=back
=head1 Context
Modified: doc/trunk/design/syn/S11.pod
==
--- doc/trunk/design/syn/S11.pod(original)
+++ doc/trunk/design/syn/S11.podWed Mar 7 20:38:15 2007
@@ -202,46 +202,72 @@
where to keep them, such that multiple versions by different authors
can coexist, all of them available to any installed version of Perl.
-The syntax of a versioned module or class declaration has three parts
-separated by hyphens. The three parts are the short name of the
-class/module, its version number, and a URI identifying the author
-(or authorizing authority). For example:
-
-class Dog-1.2.1-cpan:JRANDOM;
-class Dog-1.2.1-http://www.some.com/~jrandom;
-class Dog-1.2.1-mailto:[EMAIL PROTECTED];
-
-Such a declaration automatically aliases the full name
-of the class (or module) to the short name. So for the rest of the
-lexical scope, CDog refers to the longer name.
+The syntax of a versioned module or class declaration has multiple
+parts in which the non-identifier parts are specified in adverbial pair
+notation without intervening spaces. Internally these are stored in
+a canonical string form which you should ignore. You may write the
+various parts in any order, except that the bare identifer must come
+first. The required parts for library insertion are the short name of
+the class/module, its version number, and a URI identifying the author
+(or authorizing authority, so we call it auth to be intentionally ambiguous).
+For example:
+
+class Dog:ver1.2.1:authcpan:JRANDOM;
+class Dog:ver1.2.1:authhttp://www.some.com/~jrandom;
+class Dog:ver1.2.1:authmailto:[EMAIL PROTECTED];
+
+Since these are somewhat unweildy to look at, we allow a shorthand in
+which a bare subscripty adverb interprets its elements according to their
+form:
+
+class Dog:1.2.1 cpan:JRANDOM
+
+These declarations automatically alias the full name of the class
+(or module) to the short name. So for the rest of the lexical scope,
+CDog refers to the longer name. The real library name can be
+specified separately as another adverb, in which case the identifier
+indicates only the alias within the current lexical scope:
+
+class Pooch:nameDog:ver1.2.1:authcpan:JRANDOM
+
+or
+
+class Pooch:Dog 1.2.1 cpan:JRANDOM
+
+for short.
+
+Here the real name of the module starts CDog, but we refer to it
+as CPooch for the rest of this file. Aliasing is handy if you need to
+interface to more than one module named CDog
If there are extra classes or modules or packages declared within
the same file, they implicitly have a long name including the file's
version and author, but you needn't declare them again.
-Since these long names are the actual names of the classes, when you say:
+Since these long names are the actual names of the classes as far as
+the library system is concerned, when you say:
use Dog;
you're really wildcarding the unspecified bits:
-use Dog-(Any)-(Any);
+use Dog:ver(Any):auth(Any);
And when you say:
-use Dog-1.2.1;
+use Dog:1.2.1;
you're really asking for:
-use Dog-1.2.1-(Any);
+use Dog:ver1.2.1:auth(Any);
Saying C1.2.1 specifies an Iexact match on the version number,
not a minimum match. To match more than one version, put a range
operator in parens:
-use Dog-(1.2.1..1.2.3);
-use Dog-(1.2.1..^1.3);
-use Dog-(1.2.1..*);
+use Dog:ver(1.2.1..1.2.3);
+use Dog:ver(1.2.1..^1.3);
+use Dog:ver(1.2.1..*);
Subversions are wildcarded, so C1.2 really means C1.2.*. If you
say:
@@ -250,45 +276,45 @@
which is short for:
-use Perl-6;
+use Perl:ver6;
-you're asking for any version of Perl 6. You need to say:
+you're asking for any version of Perl 6. You need to say something like
-use Perl-6.0;
-use Perl-6.0.0;
-use Perl-6.2.7.1;
+use Perl:6.0;
+
[svn:perl6-synopsis] r14318 - doc/trunk/design/syn
Author: larry Date: Wed Mar 7 20:40:33 2007 New Revision: 14318 Modified: doc/trunk/design/syn/S02.pod Log: typo spotted by TimToady++ :/ Modified: doc/trunk/design/syn/S02.pod == --- doc/trunk/design/syn/S02.pod(original) +++ doc/trunk/design/syn/S02.podWed Mar 7 20:40:33 2007 @@ -2533,7 +2533,7 @@ =item * -A version literal are written with a 'v' followed by the version +A version literal is written with a 'v' followed by the version number in dotted form. This always constructs a CVersion object, not a string. Only integers are allowed; for anything fancier you must coerce a string to a CVersion:
[svn:perl6-synopsis] r14319 - doc/trunk/design/syn
Author: larry Date: Wed Mar 7 21:35:52 2007 New Revision: 14319 Modified: doc/trunk/design/syn/S02.pod Log: Definition of version sorting order. Modified: doc/trunk/design/syn/S02.pod == --- doc/trunk/design/syn/S02.pod(original) +++ doc/trunk/design/syn/S02.podWed Mar 7 21:35:52 2007 @@ -2546,6 +2546,44 @@ it as a named argument, in which case saying C :ver1.2.3beta is fine. See S11 for more on using versioned modules. +Version objects have a predefined sort order that follows most people's +intuition about versioning: each sorting position sorts numerically +between numbers, alphabetically between alphas, and alphabetics in a +position before numerics. Numbers ignore leading zeros. For splitting +into sort positions, if any alphabetics (including underscore) are +immediately adjacent to a number, a dot is assumed between them, +so these are all equivalent: + +1.2.1alpha1 +1.2.1.alpha1 +1.2.1alpha.1 +1.2.1.alpha.1 + +And these are also equivalent: + +1.2.1_01 +1.2.1_1 +1.2.1._1 +1.2.1_1 +1.2.1._.1 +001.0002.01._.001 + +So these are in sorted version order: + +1.2.0.999 +1.2.1_01 +1.2.1_2 +1.2.1_003 +1.2.1a1 +1.2.1.alpha1 +1.2.1b1 +1.2.1.beta1 +1.2.1.gamma +1.2.1α1 +1.2.1β1 +1.2.1γ +1.2.1 + =back =head1 Context
