[perl #63146] [TODO] Implement (*@) in the LHS of 'my' declarations
Larry (>): > Actually, that would have to be (*@) in a my, since a my takes a > signature. You can only use (*) in an ordinary list assignment: > > (*) = 5; > ($a,$b,$c,*) = @values; Ok, since the latter two work already, I'm rescuing this bug ticket by re-naming it "[TODO] Implement (*@) in the LHS of 'my' declarations". rakudo: my (*@) = 1,2,3 rakudo e73c95: OUTPUT«Statement not terminated properly at line 1, near "@) = 1,2,3" [...]
[perl #63158] wrong namespace in eval
# New Ticket Created by Ilya Belikin
# Please include the string: [perl #63158]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=63158 >
Hi there!
This is works:
our $x = 42; eval('our $x; say $x;')
but this is not:
lass TP {
has $.out is rw = '';
}
class M {
method work {
our $T = TP.new;
eval('our $T; $T.out ~= "Yay";');
say $T.out;
}
}
my $t = M.new;
$t.work;
jabber logs:
Jonathan: Oh!
I bet that the $T is being actually $M::T
And inside the eval we don't have the namespace correctly.
yes
module Foo { our $x = 42; eval('our $x; say $x;') }
}
oops
anyway, that explodes
Ticket welcome. :-)
Thank you!
Ilya Belikin aka Ihrd
Re: References to parts of declared packages
On Feb 11, 2009, at 2:46 PM, Carl Mäsak wrote:
Jon (>), Jonasthan (>>):
If we declared, for example:
role A::B {};
Then what should a reference to A be here? At the moment, Rakudo
treats it
as a post-declared listop, however I suspect we should be doing
something a
bit smarter? If so, what should the answer to ~A.WHAT be?
I'd go with one of two possibilities:
* Don't allow the declaration of A::B unless A has already been
declared.
[...]
Please don't go with this former alternative. In a project even of
moderate size like Druid, many packages of type A::B are declared
before the corresponding A package is, for perfectly legitimate
reasons.
Agree completely. Bio::* currently has the same issue.
* A should be treated as a post-declared package.
Whatever this means, it sounds preferable. :)
// Carl
Agree again. The latter is definitely preferred.
chris
[perl #63170] Null PMC access when calling method on proto-object on imported role, when the method has a parameter with another role as a type
# New Ticket Created by "Carl Mäsak"
# Please include the string: [perl #63170]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=63170 >
In Rakudo b2e7ac, Parrot r36619:
$ cat A.pm
use v6;
role A { method x(B $b) {} }
$ perl6 -e 'role B {}; use A; A.x(B)'
Null PMC access in isa()
[...]
Observations:
* The role A must be imported for this to happen.
* The parameter in method x must refer to B.
* The argument to A.x doesn't actually have to be B, or of type B. The
error occurs anyway.
r25306 - docs/Perl6/Spec
Author: lwall
Date: 2009-02-12 18:04:41 +0100 (Thu, 12 Feb 2009)
New Revision: 25306
Modified:
docs/Perl6/Spec/S10-packages.pod
docs/Perl6/Spec/S11-modules.pod
docs/Perl6/Spec/S12-objects.pod
Log:
[S10] updates to package policies
Modified: docs/Perl6/Spec/S10-packages.pod
===
--- docs/Perl6/Spec/S10-packages.pod2009-02-12 16:03:41 UTC (rev 25305)
+++ docs/Perl6/Spec/S10-packages.pod2009-02-12 17:04:41 UTC (rev 25306)
@@ -12,9 +12,9 @@
Maintainer: Larry Wall
Date: 27 Oct 2004
- Last Modified: 24 Apr 2007
+ Last Modified: 12 Feb 2009
Number: 10
- Version: 7
+ Version: 8
=head1 Overview
@@ -24,11 +24,12 @@
=head1 Packages
As in Perl 5, packages are the basis of modules and classes. Unlike in
-Perl 5, modules and classes are declared with separate keywords,
-but they're still just packages with extra behaviors.
+Perl 5, modules and classes are declared with distinct keywords,
+but they're still just packages with extra behaviors. Likewise every
+typename has an associated package namespace, even if unused.
-An ordinary package is declared with the C keyword. It can
-only be used with a block:
+An ordinary package is declared with the C keyword. Unlike in
+Perl 5, in Perl 6 it can only be used with a block:
package Bar {...} # block is in package Bar
@@ -42,29 +43,27 @@
package Foo;# the entire file is Perl 5
...
-This form is illegal in the middle of a Perl 6 file.
+This form is illegal in a Perl 6 file. If you wish to have a file-scoped
package,
+either use the brace form or declare it with the C keyword instead.
Since there are no barewords in Perl 6, package names must be predeclared,
-or use the sigil-like C<::PackageName> syntax. The C<::> prefix does not
-imply top-levelness as it does in Perl 5. (Use C<::*> for that.)
+or use the sigil-like C<::PackageName> syntax to indicate that the type will
+be supplied some other way. The C<::> prefix does not imply globalness as
+it does in Perl 5. (Use C for that.)
-A bare C declarator declares an C package within the
-current package (or module, or class, or role, or...). Use C<*>
-or C to declare a global package name.
+A bare C declarator (without an explicit scope declarator
+such as C) declares an C package within the current package
+(or module, or class, or role, or...). Use C to declare
+a global package name.
To declare a lexically scoped package, use C.
-Package names are always searched for from innermost scopes to outermost.
-As with an initial C<::>, the presence of a C<::> within the name
-does not imply globalness (unlike in Perl 5). True globals are always
-in the C namespace, which has the shortcut C<*> where that
-is not ambiguous with "real" operators.
-The C<*> namespace is not "main". The default namespace for the main
-program is C<*Main> in Perl 6. All files start out being parsed in the C<*>
-package, but switch to some other package scope depending on the first
-declaration. If that first declaration is not a package variant, then
-the parsing switches to the "C<*main>" package for Perl 5 code and the
-"C<*Main>" package for Perl 6 code.
+All files start out being parsed in the C
+package, but may switch to some other package scope depending on the first
+package-ish declaration. If that first declaration is not a package variant,
then
+the parsing switches to the "C" package for Perl 5 code. Perl 6 code
+stays C in that situation. The mainline code is thus in the
+C namespace unless declared otherwise.
Package traits are set using C:
@@ -81,6 +80,32 @@
syntax that lets you do a lookup in a particular symbol table. In this case,
the key is not parsed for C<::>. It's just a hash lookup.
+=head1 Package nesting
+
+A declaration of any object of the form C also creates (if needed)
+an empty package C, and an empty package C inside of C, in addition
to creating
+C inside of C. Such empty packages may be subsequently be redeclared as
any other
+package-like object (module, class, etc.), and no redeclaration warning will
be issued
+for such a redeclaration. If a parent package already exists, no stub package
+needs to be created, and no declaration of the form C has anything
+to say about the type of package C or package C, since any package
variant
+can function as a package for the purposes of naming things.
+
+Apart of package declaration constructs, package names are always searched
+for from the innermost lexical scope to outermost. If not defined in any
+surrounding lexical scope, the package is searched for from the current
+package up through the containing packages to C. If it is not found,
+a compiler error results.
+
+As with an initial C<::>, the presence of a C<::> within the name
+does not imply globalness (unlike in Perl 5). True globals are always
+in the C namespace.
+
+The C namespace, shared by all interpreters within the process,
+is n
r25308 - docs/Perl6/Spec
Author: lwall Date: 2009-02-12 18:50:43 +0100 (Thu, 12 Feb 2009) New Revision: 25308 Modified: docs/Perl6/Spec/S03-operators.pod Log: some cleanup suggested by Jonathan "Dataweaver" Lang++ detangling of metaoperators from metatokens "metatokens" are composed of metaoperators plus ordinary operators we shouldn't use "metaoperator" to refer to the generated operator Modified: docs/Perl6/Spec/S03-operators.pod === --- docs/Perl6/Spec/S03-operators.pod 2009-02-12 17:46:57 UTC (rev 25307) +++ docs/Perl6/Spec/S03-operators.pod 2009-02-12 17:50:43 UTC (rev 25308) @@ -12,9 +12,9 @@ Maintainer: Larry Wall Date: 8 Mar 2004 - Last Modified: 2 Feb 2009 + Last Modified: 12 Feb 2009 Number: 3 - Version: 152 + Version: 153 =head1 Overview @@ -3404,19 +3404,20 @@ turning a given existing operator into a related operator that is more powerful (or at least differently powerful). These differ from a mere naming convention in that Perl automatically generates these new -metaoperators from user-defined operators as well as from builtins. +operators from user-defined operators as well as from builtins. In fact, you're not generally supposed to define the individual metaoperations--their semantics are supposed to be self-evident by the transformation of the base operator. -Note: Spaces are never allowed between any metaoperator and the -operator it's modifying, because all operators including modified -ones have to be recognized by the Longest-Token Rule, which disallows -spaces within a token. +Constructs containing metaoperators are considered "metatokens", +by which we mean that they are not subject to ordinary longest-token +matching rules, although their components are. Like ordinary +tokens, however, metatokens do not allow whitespace between +their subparts. -=head2 Assignment metaoperators +=head2 Assignment metaoperator -These are already familiar to C and Perl programmers. (Though the +Assignment operators are already familiar to C and Perl programmers. (Though the C<.=> operator now means to call a mutating method on the object on the left, and C<~=> is string concatenation.) Most non-relational infix operators may be turned into their corresponding assignment @@ -3430,7 +3431,7 @@ Existing forms ending in C<=> may not be modified with this metaoperator. Regardless of the precedence of the base operator, the precedence -of any assignment metaoperators is forced to be the same as that of +of any assignment operator is forced to be the same as that of ordinary assignment. If the base operator is tighter than comma, the expression is parsed as item assignment. If the base operator is the same or looser than comma, the expression is parsed as a list assignment: @@ -3716,8 +3717,7 @@ =head2 Reduction operators -The fourth metaoperator in Perl 6 is the reduction operator. Any -infix operator (except for non-associating operators) +Any infix operator (except for non-associating operators) can be surrounded by square brackets in term position to create a list operator that reduces using that operation: @@ -3725,8 +3725,7 @@ my @a = (5,6); [*] @a; # 5 * 6 = 30 -As with all the metaoperators, space is not allowed inside. The whole -thing parses as a single token. +As with all the metaoperators, space is not allowed inside a metatoken. A reduction operator has the same precedence as a list operator. In fact, a reduction operator really is a list operator, and is invoked as one. @@ -3946,11 +3945,11 @@ =head2 Cross operators -The final metaoperator is the cross metaoperator. It is formed syntactically -by placing an infix operator after the C character. It applies the +The cross metaoperator, C, may be followed by any infix operator. +It applies the modified operator across all groupings of its list arguments as returned by the ordinary C<< infix: >> operator. All -cross operators are of list infix precedence, and are list associative. +generated cross operators are of list infix precedence, and are list associative. The string concatenating form is: @@ -3986,7 +3985,7 @@ (Note that C<< <== >> and C<< ==> >> are considered mutating, as well as all assignment operators.) -If the underlying operator is non-associating, so is the metaoperator: +If the underlying operator is non-associating, so is the cross operator: @a Xcmp @b Xcmp @c # ILLEGAL @a Xeq @b Xeq @c # ok @@ -4002,15 +4001,9 @@ =head2 Nesting of metaoperators -Constructs containing metaoperators are considered "metatokens", -by which we mean that they are not subject to ordinary longest-token -matching rules, although their components are. Like ordinary -tokens, however, metaoperators do not allow whitespace between -their subparts. - Any ordinary infix operator may be enclosed in square brackets with the same meaning. You may therefore use square br
Re: S03: how many metaoperators?
On Wed, Feb 11, 2009 at 02:23:15PM -0800, Jon Lang wrote: : With the addition of the reversing metaoperator, the claim that there : are six metaoperators (made in the second paragraph of the meta : operators section) is no longer true. Count again. : Likewise, the reduction : operator is no longer the fourth metaoperator (as stated in the first : sentence of the reduction operators section). For now, the cross : operator _is_ still the final metaoperator, as it states in its first : paragraph; but it's possible that that might change eventually. Indeed. Thanks. Larry
r25310 - docs/Perl6/Spec
Author: lwall Date: 2009-02-12 19:23:25 +0100 (Thu, 12 Feb 2009) New Revision: 25310 Modified: docs/Perl6/Spec/S03-operators.pod Log: failure of parallelism in headings Modified: docs/Perl6/Spec/S03-operators.pod === --- docs/Perl6/Spec/S03-operators.pod 2009-02-12 18:12:52 UTC (rev 25309) +++ docs/Perl6/Spec/S03-operators.pod 2009-02-12 18:23:25 UTC (rev 25310) @@ -1434,7 +1434,7 @@ += -= **= xx= .= etc. -See L. +See L. =back @@ -3415,7 +3415,7 @@ tokens, however, metatokens do not allow whitespace between their subparts. -=head2 Assignment metaoperator +=head2 Assignment operators Assignment operators are already familiar to C and Perl programmers. (Though the C<.=> operator now means to call a mutating method on the object on
Re: [perl #46503] [TODO] Remove individual runcore command line flags...
On Wed, Feb 11, 2009 at 5:42 PM, Will Coleda via RT < parrotbug-follo...@parrotcode.org> wrote: > On Fri Oct 19 17:20:38 2007, particle wrote: > > i suggest we migrate all existing code to the new options at once, and > > mark the old options as deprecated. however, i'd like to see the old > > options stay around for a while, perhaps with a runtime warning after > > the 0.5.0 release, a fatal error after 0.6.0, and removal in 0.7.0. > > those last two release numbers are flexible > > Adding as a DEPRECATION item so we can rip these out before 1.0 The attached patch adds the mentioned deprecation warnings to this options. "make test" continues to pass. -- Daniel Arbelo Arrocha warn_deprecated_bCfgjS_opts.patch Description: Binary data
Re: [perl #57764] docs/art/ppp02-pmc.pod -- example 9 segfault
On Thursday 12 February 2009 13:14:42 Will Coleda via RT wrote: > Here's a shorter example that still generates a bus error for me on > darwin/x86 Oh look, it's an order of destruction problem. > And here's a partial bt from the bus error: > #0 0x0001 in ?? () > #1 0x0107f318 in Parrot_exit (interp=0x600cb0, status=1) at > src/exit.c:91 > #2 0x0107e462 in die_from_exception (interp=0x600cb0, > exception=0x2fa9f0) at src/exceptions.c:159 > #3 0x0107e521 in Parrot_ex_throw_from_c (interp=0x600cb0, > exception=0x2fa9f0) at src/exceptions.c:308 > #4 0x0107ec7f in Parrot_ex_throw_from_c_args (interp=0x600cb0, > ret_addr_unused=0x0, exitcode=62, format=0x1314724 "maximum recursion > depth exceeded") at src/exceptions.c:409 > #5 0x0119f660 in Parrot_Sub_invoke (interp=0x600cb0, pmc=0x2c19c0, > next=0x0) at ./src/pmc/sub.pmc:268 ... > #11 0x0109a292 in Parrot_really_destroy (interp=0x600cb0, > exit_code_unused=1, arg_unused=0x0) at src/inter_create.c:324 -- c
Re: [perl #39714] [TODO] Refactor IMCC to remove static globals
On Thu, Feb 12, 2009 at 9:22 PM, Will Coleda via RT < parrotbug-follo...@parrotcode.org> wrote: > On Tue Jul 04 19:30:44 2006, autri...@gmail.com wrote: > > IMCC currently relies on a lot of static globals to carry state, and > > cannot reliably restore them when an error occurs. (grep for > > "static" and "FIXME global" in the IMCC tree.) > > > > Allison had ruled that reentrancy should be possible for IMCC, and > > this would be a good refactoring project. > > We've rejected a lot of "clean up IMCC" tickets with the thought that we > eventually want PIRC to take over. Anyone think this falls into the same > category? > I would like to indicate that while most of PIRC's done, it's not finished yet. Major issue now is the bug with STRING and FLOATVAL constants bug (there's 1 or 2 tickets on that). I haven't really had the energy or time to work on that recently. The rest is just a matter of test+fix cycle; I'm sure there's all sorts of cases that should be tested more properly than I've done. So, although I'm confident that together we can fix PIRC, don't throw out imcc just yet.. kjs > > -- > Will "Coke" Coleda > ___ > http://lists.parrot.org/mailman/listinfo/parrot-dev >
Re: [perl #39714] [TODO] Refactor IMCC to remove static globals
On Thu, Feb 12, 2009 at 6:09 PM, kjstol wrote: > On Thu, Feb 12, 2009 at 9:22 PM, Will Coleda via RT < > parrotbug-follo...@parrotcode.org> wrote: > >> On Tue Jul 04 19:30:44 2006, autri...@gmail.com wrote: >> > IMCC currently relies on a lot of static globals to carry state, and >> > cannot reliably restore them when an error occurs. (grep for >> > "static" and "FIXME global" in the IMCC tree.) >> > >> > Allison had ruled that reentrancy should be possible for IMCC, and >> > this would be a good refactoring project. >> >> We've rejected a lot of "clean up IMCC" tickets with the thought that we >> eventually want PIRC to take over. Anyone think this falls into the same >> category? >> > > I would like to indicate that while most of PIRC's done, it's not finished > yet. Major issue now is the bug with STRING and FLOATVAL constants bug > (there's 1 or 2 tickets on that). I haven't really had the energy or time to > work on that recently. The rest is just a matter of test+fix cycle; I'm sure > there's all sorts of cases that should be tested more properly than I've > done. So, although I'm confident that together we can fix PIRC, don't throw > out imcc just yet.. > > kjs To be clear, I'm not saying "throw out IMCC", I'm saying, "Let's not bother trying to fix tricky bits of IMCC if we're just going to throw it out later." -- Will "Coke" Coleda
Re: [perl #39714] [TODO] Refactor IMCC to remove static globals
On Thu, Feb 12, 2009 at 15:53, Will Coleda wrote: > On Thu, Feb 12, 2009 at 6:09 PM, kjstol wrote: >> On Thu, Feb 12, 2009 at 9:22 PM, Will Coleda via RT < >> parrotbug-follo...@parrotcode.org> wrote: >> >>> On Tue Jul 04 19:30:44 2006, autri...@gmail.com wrote: >>> > IMCC currently relies on a lot of static globals to carry state, and >>> > cannot reliably restore them when an error occurs. (grep for >>> > "static" and "FIXME global" in the IMCC tree.) >>> > >>> > Allison had ruled that reentrancy should be possible for IMCC, and >>> > this would be a good refactoring project. >>> >>> We've rejected a lot of "clean up IMCC" tickets with the thought that we >>> eventually want PIRC to take over. Anyone think this falls into the same >>> category? >>> >> >> I would like to indicate that while most of PIRC's done, it's not finished >> yet. Major issue now is the bug with STRING and FLOATVAL constants bug >> (there's 1 or 2 tickets on that). I haven't really had the energy or time to >> work on that recently. The rest is just a matter of test+fix cycle; I'm sure >> there's all sorts of cases that should be tested more properly than I've >> done. So, although I'm confident that together we can fix PIRC, don't throw >> out imcc just yet.. >> >> kjs > > To be clear, I'm not saying "throw out IMCC", I'm saying, "Let's not > bother trying to fix tricky bits of IMCC if we're just going to throw > it out later." > i want to go into production (1.0) knowing what's broken in imcc rather than hiding the broken things in closed/rejected tickets. what do we get by hiding bugs? surprises. i could use fewer of those--my teeth still hurt from that surprise trip to the dentist this week. ~jerry
S06: named arguments and long names
Are required named parameters (e.g., ':$foo!') considered to be part of the long name provided by a signature? (S06 seems to indicate that they aren't.) Either way, can their status with respect to the long name be changed? That is, if they aren't included in the long name, can they be added to it? If they are included, can they be removed? Suggestion: exclude them by default; but use a double exclamation mark to indicate a required named parameter that is included in the long name. ':$foo!' would not be part of the long name, but ':$foo!!' would be. -- Jonathan "Dataweaver" Lang
PCT via Perl6: success!
I just finished converting Perk (a Java compiler targeting Parrot) from PCT+NQP/PIR to PCT+Rakudo. That is, the main entry point and actions.pm for my compiler are written in Perl 6. http://github.com/chrisdolan/perk/tree/master I had to make a few little hacks along the way: * PCT::HLLCompiler.parsegrammar() and .parseaction() require Parrot strings as arguments, not Rakudo strings. So, I used .WHICH as a hack to downconvert. * I couldn't figure out how to call 'compreg' from Rakudo, so I used inline PIR * a '>' token in my grammar couldn't find the token in the grammar, so I had to fully qualify it as . This is probably because the grammar is declared from Rakudo vs. compiled directly from PGE. Happily, I didn't need to change a single line of code in my actions.pm -- with the new 'make' builtin, my NQP code is fully supported by Rakudo. It would be interesting to see what remaining NQP constructs are not supported under Rakudo. Chris
