[perl #41726] [PATCH] make lua fail more gracefully with an exception handler
# New Ticket Created by "Julian Fondren" # Please include the string: [perl #41726] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=41726 > Currently, evaluating this: function bad (n) return n * bad(n) end bad(2) will cause lua to produce -- infinitely, and very quickly -- ungraceful error messages. (It will do this on any excess-recursion error -- I first saw this behavior when I passed too-large a number to a simple factorial function.) The attached patch causes lua to generate .pir files that push this exception handler before evaluating any compiled-lua code: root_exception_handler: get_results '(0, 0)', $P0, $S0 $S0 = $P0[0] print "Unhandled exception: " print $S0 print "\n" exit 1 I already sent this to Klaas-Jan Stol <[EMAIL PROTECTED]> , but when I didn't get a reply or see the change in svn after a few days, I RTFM'd on contributing patches. Cheers, Julian --- languages/lua/Lua/pir.pm2007-03-07 16:26:54.0 +0900 +++ languages/lua/Lua/pir.pm2007-03-07 16:26:49.0 +0900 @@ -22,6 +22,7 @@ $P0 = new .Array set $P0, $I0 $I1 = 0 + push_eh root_exception_handler L1: unless $I1 < $I0 goto L2 $S0 = shift args @@ -43,7 +44,16 @@ load_bytecode 'languages/lua/lib/luaos.pbc' load_bytecode 'languages/lua/lib/luadebug.pbc' load_bytecode 'languages/lua/lib/luaperl.pbc' - _main($P0 :flat) + .return _main($P0 :flat) + + # a convenient place? +root_exception_handler: + get_results '(0, 0)', $P0, $S0 + $S0 = $P0[0] + print "Unhandled exception: " + print $S0 + print "\n" + exit 1 .end .sub '__onload' :anon :init Index: CREDITS === --- CREDITS (revision 17374) +++ CREDITS (working copy) @@ -313,6 +313,9 @@ N: Juergen Boemmels D: Parrot I/O; macro stuff in assembler. +N: Julian Fondren +E: [EMAIL PROTECTED] + N: Karl Forner D: shootout examples testing E: [EMAIL PROTECTED]
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 I; 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 C can mark part of its parameters to
+be considered in the multi dispatch. These are called I;
+see S12 for more about the semantics of multiple dispatch.
-If the parameter list for a C contains no semicolon to delimit
+You can choose part of a C'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 C contains no semicolons to delimit
the list of important parameters, then all positional parameters are
considered important. If it's a C or C,
an additional implicit unnamed C 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
[perl #41732] [BUG] parrot objects segfault on improper invoke override
# New Ticket Created by Will Coleda # Please include the string: [perl #41732] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=41732 > The following (improper?) code segfaults: .namespace ['Foo'] .sub __invoke :method .param pmc a say 'hi' .end .sub main :main $P0 = newclass "Foo" $P1 = new "Foo" $P1() .end Removing the __invoke method generates a method not found error, avoiding the segfault. Removing the .param also avoids the segfault. Changing the override to "invoke :vtable" avoids the segault.
Re: [perl #41724] [BUG] miniparrot fails to build on strawberry perl
Jerry Gay (via RT) ha scritto: i suspect there's trouble with the platform-specific c/h files, given the nature of the warnings during build. the configure/make output is below. the only relevant warning I see is: config/gen/platform/win32/exec.c: In function `Parrot_Exec_OS_Command': config/gen/platform/win32/exec.c:182: warning: passing arg 2 of `_execvp' from i ncompatible pointer type this seems to be generated by the difference between 'char **' and 'char* const*'. I don't think this is a great problem. Invoking Parrot to generate runtime/parrot/include/config.fpmc --cross your fing ers ./miniparrot.exe config_lib.pasm > runtime/parrot/include/config.fpmc '.' is not recognized as an internal or external command, operable program or batch file. make: *** [runtime/parrot/include/config.fpmc] Error 1 these last lines seem to suggest that miniparrot.exe was in fact built. the problem, I think, is that make is trying to call miniparrot prepending './', which is sh-style and does not work under Windows CMD. you may have better luck running make from a cygwin shell. or perhaps you could try mingw32-make instead of make as Configure.pl suggests? on the other hand, I had a totally different experience using strawberry perl to build parrot. it doesn't work at all, make groks because of backslashes in paths in the Makefile (had to change them to forward slashes), libparrot.dll refuses to build because, apparently, g++ is unable to link correctly (it says: "cc1.exe \: no such file or directory"). YMMV. cheers, Aldo
Re: [perl #41724] [BUG] miniparrot fails to build on strawberry perl
On Wednesday 07 March 2007 08:42, Aldo Calpini wrote: > on the other hand, I had a totally different experience using strawberry > perl to build parrot. it doesn't work at all, make groks because of > backslashes in paths in the Makefile (had to change them to forward > slashes), libparrot.dll refuses to build because, apparently, g++ is > unable to link correctly (it says: "cc1.exe \: no such file or > directory"). YMMV. Our configuration process tends to assume a tight connection between the operating system and a specific compiler, for example. -- c
[perl #41733] invoke :vtable - execution stops
# New Ticket Created by [EMAIL PROTECTED] # Please include the string: [perl #41733] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=41733 > Hi There, Given the following (latest svn today - parrot 0.49+): .namespace ['Foo'] .sub invoke :vtable say "you invoked me!" .return() .end .sub main :main $P0 = newclass "Foo" $P1 = new "Foo" $P1() say "got here" .end The final "got here" is never printed. Also parrot segfaults with the signature: .sub invoke :vtable :method ... .end Not sure if that's allowed (:vtable :method), though. Cheers, Rich
Re: [perl #41712] [TODO] deprecate CSub
Jerry Gay (via RT) wrote: it's old, not used anywhere, and defunct. let's list it in DEPRECATED.pod before 0.4.10, and remove it before the following release. Agree. Allison
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. > 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
Re: [perl #41712] [TODO] deprecate CSub
On 3/7/07, Allison Randal <[EMAIL PROTECTED]> wrote: Jerry Gay (via RT) wrote: > it's old, not used anywhere, and defunct. let's list it in > DEPRECATED.pod before 0.4.10, and remove it before the following > release. Agree. i've added a note to DEPRECATED.pod, in preparation for the 0.4.10 release. ~jerry
[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 +C, but since the C type is not a real instantiable +type but a generic (non)constraint, and C is sort of +a double non-constraint similar to C, 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:parrot-pdd] r17380 - trunk/docs/pdds
Author: particle Date: Wed Mar 7 16:38:50 2007 New Revision: 17380 Modified: trunk/docs/pdds/pdd22_io.pod Log: [PDD22]: ~ added note about Status PMC passing for async ops ~ added Status PMC return value for I/O print method ~ renumbered example code registers for consistency ~ expanded tabs to spaces Modified: trunk/docs/pdds/pdd22_io.pod == --- trunk/docs/pdds/pdd22_io.pod(original) +++ trunk/docs/pdds/pdd22_io.podWed Mar 7 16:38:50 2007 @@ -79,7 +79,9 @@ task is handled by a shared status object. The operation task updates the status object whenever the status changes, and the calling code can check the status object at any time. The status object contains a -reference to the returned result of an asynchronous I/O call. +reference to the returned result of an asynchronous I/O call. In order +to allow sharing of the status object, asynchronous ops both pass the +status object to the callback PMC, and return it to the calling code. The lightweight tasks typically used by the asynchronous I/O system capture no state other than the arguments passed to the I/O call, and @@ -147,16 +149,17 @@ =item print - $P0.print($I1) - $P0.print($N1) - $P0.print($S1) - $P0.print($P1) - $P0.print($I1, $P2) - $P0.print($N1, $P2) - $P0.print($S1, $P2) - $P0.print($P1, $P2) + $P0 = $P1.print($I2) + $P0 = $P1.print($N2) + $P0 = $P1.print($S2) + $P0 = $P1.print($P2) + $P0 = $P1.print($I2, $P3) + $P0 = $P1.print($N2, $P3) + $P0 = $P1.print($S2, $P3) + $P0 = $P1.print($P2, $P3) Writes an integer, float, string, or PMC value to an I/O stream object. +Returns a PMC status object. The asynchronous version takes an additional final PMC callback argument $P2. When the print operation is complete, it invokes the callback, @@ -285,7 +288,7 @@ =item get_bool (vtable) - if $P1 goto ... + if $P0 goto ... Returns a boolean status for the status object, C for successful completion or while still running, C for an error. @@ -625,10 +628,10 @@ 0PIOCTL_NONBUF Unbuffered I/O. Bytes are sent as soon as possible. 1PIOCTL_LINEBUF - Line buffered I/O. Bytes are sent when a newline is + Line buffered I/O. Bytes are sent when a newline is encountered. 2PIOCTL_BLKBUF - Fully buffered I/O. Bytes are sent when the buffer is full. + Fully buffered I/O. Bytes are sent when the buffer is full. =back @@ -673,7 +676,7 @@ 7STAT_CHANGETIME The last time the file metadata was changed. 8STAT_BACKUPTIME - The last time the file was backed up. + The last time the file was backed up. (Currently just returns -1.) 9STAT_UID The user ID of the file.
Re: [perl #41733] invoke :vtable - execution stops
The invoke vtable method is supposed to take one argument - the
address of the opcode immediately following the invokecc opcode, so we
can return to it later. It then returns the address of the subroutine
to jump into. The problem is that, in C, the invoke method takes and
returns an opcode_t*, and PIR can't handle that, so I've attached a
patch correcting the problem by converting the argument and return
value so the PIR plays nice.
Any ParrotObject overriding the invoke vtable method is probably not
going to care about addresses. Luckily, all we have to do is return
the address we're given, so everything goes back to normal after the
method's finished. The downside is that you're going to have to come
with a more creative workaround in order to be passed any arguments
that the method is called with.
.namespace ['Foo']
.sub __invoke :method
.param int address
say "you invoked me!"
.return(address)
.end
.sub main :main
$P0 = newclass "Foo"
$P1 = new "Foo"
$P1()
say "got here"
.end
Thanks,
Alek Storm
On 3/7/07, via RT richard @ hive-systems. com
<[EMAIL PROTECTED]> wrote:
# New Ticket Created by [EMAIL PROTECTED]
# Please include the string: [perl #41733]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=41733 >
Hi There,
Given the following (latest svn today - parrot 0.49+):
.namespace ['Foo']
.sub invoke :vtable
say "you invoked me!"
.return()
.end
.sub main :main
$P0 = newclass "Foo"
$P1 = new "Foo"
$P1()
say "got here"
.end
The final "got here" is never printed.
Also parrot segfaults with the signature:
.sub invoke :vtable :method
...
.end
Not sure if that's allowed (:vtable :method), though.
Cheers,
Rich
--- src/pmc/delegate.pmc 2007-02-24 13:38:07.0 +
+++ src/pmc/delegate.pmc 2007-03-07 17:51:42.0 +
@@ -167,6 +167,19 @@
/* don't delegate mark */
}
+void* invoke(void* next) {
+STRING *meth = CONST_STRING(interp, "__invoke");
+STRING *meth_v = CONST_STRING(interp, "invoke");
+PMC *sub = Parrot_find_vtable_meth(INTERP, SELF, meth_v);
+if (PMC_IS_NULL(sub))
+sub = find_or_die(interp, SELF, meth);
+
+/* convert argument from ptr into int for passing into PIR, then
+ convert return value back from int into ptr */
+return INTVAL2PTR(opcode_t *, Parrot_run_meth_fromc_args_reti(interp, sub,
+pmc, meth, "II", PTR2INTVAL(next)));
+}
+
PMC* instantiate(PMC* sig) {
STRING *meth = const_string(INTERP,
PARROT_VTABLE_INSTANTIATE_METHNAME);
Re: [perl #41733] invoke :vtable - execution stops
Alek Storm <[EMAIL PROTECTED]> wrote:
The invoke vtable method is supposed to take one argument - the
address of the opcode immediately following the invokecc opcode, so we
can return to it later. It then returns the address of the subroutine
to jump into. The problem is that, in C, the invoke method takes and
returns an opcode_t*, and PIR can't handle that, so I've attached a
patch correcting the problem by converting the argument and return
value so the PIR plays nice.
Any ParrotObject overriding the invoke vtable method is probably not
going to care about addresses. Luckily, all we have to do is return
the address we're given, so everything goes back to normal after the
method's finished. The downside is that you're going to have to come
with a more creative workaround in order to be passed any arguments
that the method is called with.
I don't think that's the right route to take. Exposing the pc to PIR-land
code seems dangerous and I don't think there's much point. As a PIR user, I
want the invoke vtable to behave just like any other PIR subroutine.
This gets us close to what I want:
void* invoke(void *next) {
STRING *meth = CONST_STRING(interp, "__invoke");
STRING *meth_v = CONST_STRING(interp, "invoke");
PMC *sub = Parrot_find_vtable_meth(interp, pmc, meth_v);
if (PMC_IS_NULL(sub))
sub = find_or_die(interp, pmc, meth);
(void*) Parrot_run_meth_fromc_args(interp, sub,
pmc, meth, "??", next);
return next;
}
I've tested it and it works with the original code that Richard gave. The
only thing left to do is handle return values; I'm still working on that. If
I can get return values working properly, I'll check in a fix.
--
Matt Diephouse
http://matt.diephouse.com
Re: [perl #41733] invoke :vtable - execution stops
On Wednesday 07 March 2007 17:02, Matt Diephouse wrote:
> I don't think that's the right route to take. Exposing the pc to PIR-land
> code seems dangerous and I don't think there's much point. As a PIR user, I
> want the invoke vtable to behave just like any other PIR subroutine.
Agreed.
> This gets us close to what I want:
>
>
>
> void* invoke(void *next) {
>
> STRING *meth = CONST_STRING(interp, "__invoke");
>
> STRING *meth_v = CONST_STRING(interp, "invoke");
>
> PMC *sub = Parrot_find_vtable_meth(interp, pmc, meth_v);
>
> if (PMC_IS_NULL(sub))
>
> sub = find_or_die(interp, pmc, meth);
>
> (void*) Parrot_run_meth_fromc_args(interp, sub,
>
> pmc, meth, "??", next);
That probably works, with the caveat that the Parrot_run_*_fromc*() functions
seem to have big problems with multisubs.
-- c
Re: Weekly Perl 6 mailing list summary for 18-24 March, 2007
On Sun, 4 Mar 2007, Will Coleda wrote: Good News: Thanks for the Summaries! Bad News: Isn't that in about 2 weeks? ^_^ I realized the mistake after I posted it. I corrected the web posts but it's rather hard to correct email. At Darren Duncan's suggestion, I will repost with the correct subject. - Ann
[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 C (in a suitable container) works as in Perl 5.
-(Use a derived type or a lexical multi to change this.) Perl 6 also
-supports C decrement.
+Increment of a C (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 C decrement.
+
+Increment and decrement are defined in terms of the C<.succ> and
+C<.pred> methods on the type of object in the C 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 C (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 C, in which case decrement actually deletes it
from the C.
@@ -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 C 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 C 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
+C changes its direction, it swaps its C<.from> and C<.to> but
+not its C<.min> and C<.max>.
Because C objects are lazy, they do not automatically generate
-a list. So smart matching against a C object smartmatches the
+a list. One result of this is that a reversed C object is still lazy.
+Another is that smart matching against a C object smartmatches the
endpoints in the domain of the object being matched, so fractional
numbers are C 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:
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: C<2..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 C 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
Parrot 0.4.10 (Coming Soon)
Release is a little under two weeks away... There's a placeholder ticket here: http://rt.perl.org/rt3/Ticket/Display.html?id=41581 Which contains all the tickets (so far) I'd preferentially like to see resolved before the next release. If you've got something you're working on that you think you'll be getting done before the release, please - add a ticket for it (if necessary); - add it as a dependency for this ticket I suspect we'll have another "Bug Day" the weekend before the release. More on that later. Thanks in advance for your patches and commits. ^_^ -- Will "Coke" Coleda [EMAIL PROTECTED]
[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 C object, not
+a string. Only integers are allowed; for anything fancier you must
+coerce a string to a C:
+
+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<< :ver<1.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, C 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:ver<1.2.1>:auth;
+class Dog:ver<1.2.1>:auth;
+class Dog:ver<1.2.1>:auth;
+
+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,
+C 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:name:ver<1.2.1>:auth
+
+or
+
+class Pooch:
+
+for short.
+
+Here the real name of the module starts C, but we refer to it
+as C for the rest of this file. Aliasing is handy if you need to
+interface to more than one module named C
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:ver<1.2.1>:auth(Any);
Saying C<1.2.1> specifies an I 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 C<1.2> really means C<1.2.*>. If you
say:
@@ -250,45 +276,45 @@
which is short for:
-use Perl-6;
+use Perl:ver<6>;
-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>;
+use Perl:<6.0.0>;
+use Perl:<6.2.7.1>;
if you
[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 C object, not a string. Only integers are allowed; for anything fancier you must coerce a string to a C:
[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<< :ver<1.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
