Re: [perl #78112] [BUG] Null PMC access when using placeholder parameter in rhs of attribute assignment in class declaration in Rakudo
std seems to complain that the placeholder variables are not valid here.
Maybe we need more clarification on whether this should work or not.
std: class A {has $.a = $^b + 1 }; say A.new(1).a
std 237d266: OUTPUT«[31m===[0mSORRY![31m===[0mPlaceholder variable
$^b may not be used here because the surrounding package block takes no
signature at /tmp/Fx9q_bkcz8 line 1:--> [32mclass A {has $.a =
$^b[33m⏏[31m + 1}; say A.new(1).a
--
John Harrison
On Tue, Sep 28, 2010 at 5:34 PM, Carl Mäsak wrote:
> # New Ticket Created by "Carl Mäsak"
> # Please include the string: [perl #78112]
> # in the subject line of all future correspondence about this issue.
> # http://rt.perl.org/rt3/Ticket/Display.html?id=78112 >
>
>
> rakudo: class A {has $.a = $^b + 1;has $.b = $^a }; say
> A.new(1,2).a
> rakudo 624188: OUTPUT«Null PMC access in type() [...]
> * masak submits rakudobug
> rakudo: class A { has $.a = $^b }; A.new
> rakudo 624188: OUTPUT«Null PMC access in isa_pmc() [...]
>
Re: [perl #78156] AutoReply: [BUG] Null PMC access on does Callable
This appears to only happen on mutli subs but I am still looking for other
causes.
--
John Harrison
On Fri, Oct 1, 2010 at 11:11 AM, perl6 via RT
wrote:
> Greetings,
>
> This message has been automatically generated in response to the
> creation of a trouble ticket regarding:
>"[BUG] Null PMC access on does Callable",
> a summary of which appears below.
>
> There is no need to reply to this message right now. Your ticket has been
> assigned an ID of [perl #78156].
>
> Please include the string:
>
> [perl #78156]
>
> in the subject line of all future correspondence about this issue. To do
> so,
> you may reply to this message.
>
>Thank you,
>perl6-bugs-follo...@perl.org
>
> -
> Some subs can 'does Callable' while other return Null PMC access errors.
>
> rakudo: say &print does Callable
> rakudo 8827d0: OUTPUT«Null PMC access in clone() in
> 'infix:' at line 37 in 'infix:' at line 537:CORE.setting in
> main program body at line 22:/tmp/NXqor71nBI»
> oo
> rakudo: sub foo {}; say &foo does Callable
> rakudo 8827d0: OUTPUT«foo»
>
> --
> John Harrison
>
>
Re: slurpy hash
One thing also worth noting is that $1 is an alias to $/[1].
perl6
> my $1 = 2; say $1;
2
> my $1 = 2; say $/[1];
2
Also, $ is an alias to $/. This would make them rather difficult
to use in parameters, IMO.
--
John Harrison
On Wed, Aug 18, 2010 at 3:12 AM, Moritz Lenz wrote:
>
>
> Am 18.08.2010 01:33, schrieb Darren Duncan:
>
> David H. Adler wrote:
>>
>>> Hm. So how are valid parameter names defined? Identifiers in perl6 seem
>>> to be composed of letters, digits and underscores (and hyphens and
>>> apostrophes between letters).
>>>
>>
> That's correct.
>
>
> Are parameter names defined differently?
>>
>
> Yes and no. If you want to use the normal syntax like this:
>
> sub f(:$named-name) { ... }
>
> your indeed limited to identifiers. But with slurpy hashes you can use any
> key, really:
>
> sub f(*%h) {
> say %h{ '++' };
> }
> f(|{ '++' => 'non-identifier names work'})
>
> However this is rather clumsy, and should be reserved for interoperation
> with other languages which have different ideas of what an identifier is.
>
>
> You certainly seem to be able to declare a variable $1.
>>>
>>
> If Rakudo allows that, it's a bug. STD.pm6, Larry's Perl 6 grammar, says
> "Can't declare a numeric variable" about it.
>
>
> I believe that Perl 6 identifiers can be any string at all, but that
>> then they have to appear quoted in the general case;
>> the above
>> restriction just refers to the common case of unquoted identifiers. This
>> said, I'm not sure yet what the syntax is for quoting identifiers. --
>>
>
> This distinction is new to me. For "identifier" means what you call
> "unquoted identifier", and my reading of the synopsis so far hasn't
> contradicted that unerstanding in any way.
>
> But that's really a question of how you call stuff - your explanation is
> correct, as I demonstrated above.
>
> Cheers,
> Moritz
>
Re: Methodicals: A better way to monkey type
Ruby has a similar functionality that lets you define methods on an instance
object. Really, its how class methods are specified, you just put the class
name as the name of the object. Here is an example:
a = Object.new
def a.foo
puts "foo and #{self}"
end
They will stay on the object as long as the object exists. So, if its a
scoped variable, it will go away when you leave the scope.
--
John Harrison
On Wed, Apr 21, 2010 at 7:49 AM, Andrew Whitworth wrote:
> This idea strikes me as being extremely similar to C#'s extension
> methods, a feature that I've found to be particularly beneficial in
> many cases. The fact that these methodicals are lexically-scoped is
> especially nice, and the fact that they can be applied post-hoc to
> arbitrary data items that have no prior support for them (like Parrot
> objects) would be very nice to have on Parrot in particular where
> language interoperation could be a big deal in the future.
>
> +1
>
> --Andrew Whitworth
>
>
>
> On Wed, Apr 21, 2010 at 3:16 AM, Stefan O'Rear wrote:
> > (The following describes a proposed extension to Perl 6, methodical
> scoped
> > operators or methodicals for short. It is written in the present tense
> for
> > simplicity but should be understood as the future conditional.)
> >
> > Normally, when you write a method call, the definition of the method is
> > entirely in the domain of the receiver's class:
> >
> >$object.make-me-a-sandwich; # $object gets to decide what this means
> >
> > However, this is not always how things work.
> >
> >$object.WHAT; # Larry says that WHAT should return the protoobject
> >
> > WHAT, WHENCE, postcircumfix:<[ ]>, and similar operators have semantics
> > (although not implementation) defined by the language itself. Currently,
> Perl 6
> > fakes this by having all values inherit from Any or Mu or Cool, which
> define
> > the basic, overridable versions of these method-like operators. This
> cheat
> > actually works pretty well in a homogeneous environment, but it fails if
> we have
> > to consider objects from outside Perl 6.
> >
> >$parrot-array.WHAT; # Method WHAT not found for invocant of type ...
> >
> > The problem here is that scopes are conflated - WHAT is defined by the
> > language, which is approximately a lexical scope, while methods on an
> object
> > are in some entirely different scope.
> >
> > A methodical is an operator which syntactically behaves as a method but
> is
> > subject to scoping rules. Methodicals are defined using the ordinary
> method
> > keyword, qualified with my or our. (TODO: This seems the most natural
> syntax
> > to me, but it conflicts with existing usage. Which is more worth having
> on
> > it?) Methodicals do not need to be declared in classes, but they should
> > generally have declared receiver types.
> >
> >{
> >my method make-me-a-sandwich(Num:) { ... }
> >
> >2.make-me-a-sandwich; # calls our method
> >
> >"ham".make-me-a-sandwich; # either an error, or method dispatch
> >}
> >
> >2.make-ma-a-sandwich; # ordinary method dispatch
> >
> > The primary use case for methodicals is naturally in the setting. Many
> of the
> > methods which are currently defined on lower-level types could become
> > methodicals and they would be available on all values, in any code
> compiled
> > within the Perl 6 setting, without polluting the referencing environments
> of
> > non-Perl 6 code in the same object environment.
> >
> >my method WHAT($thing) { ... }
> >
> > Rakudo already uses something very much like an ad-hoc direct
> implementation of
> > methodicals to handle postcircumfix operators.
> >
> > Methodicals are also useful in user code where the most natural phrasing
> of a
> > calculation is as a property of a system type, for instance from the
> Mandelbrot
> > Advent example:
> >
> >my method mandel(Complex:) {
> >my $z = 0i;
> >for ^$max-iterations {
> >$z = $z * $z + self;
> >return 1 if ($z.abs > 2);
> >}
> >return 0;
> >}
> >
> > Since methodicals do not pollute global referencing environments, and do
> not
> > compromise encapsulation, MONKEY_TYPING is not needed here.
> >
> > A methodical defined inside a class functions much like a private method.
> > There may be something interesting here, but I'm not entirely sure what.
> >
> > There ar
Re: Symbol '$x' not predeclared in
Each line is executed independently. Local variables from 1 line of code will not persist between returns. Some things do persist though, classes for instance will persist, roles will persist, grammars will persist, but sub routines will not, neither will variables. I believe there are plans for some improvements, eventually, but right now its fairly simplistic. On Tue, Mar 9, 2010 at 11:42 AM, Kiffin Gish wrote: > I want to play around with perl6 and see what it can do. > > $ cd rakudo > $ ./perl6 > > my $x = 8 > > say $x > Symbol '$x' not predeclared in > > How can I define variables and use them later? > > -- > Kiffin Gish > Gouda, The Netherlands > > > -- John "ash" Harrison
Re: Custom errors on subsets?
Would it make sense to have the failure bound to the function parameter
rather than the subset? eg.:
sub foo (Str $name where { $_ ~~ :f } else { die "Houston, we don't have a
file" } ) { ... }
Just a thought...
On Tue, Jan 5, 2010 at 1:07 AM, Ovid
wrote:
> --- On Mon, 4/1/10, yary wrote:
>
> > From: yary
>
> > How about
> > multi sub foo(Any $name) { die "Houston, we have a major
> > malfunction."}
>
> Looks like tha would work, but it forces the developer to remember to write
> this extra code every time they may have a constraint failure, if they
> forget, we're back to the old, cryptic message. It would be much nicer to
> be able to do this (psuedo-code, obviouly):
>
> subset Filename of Str where { $_ ~~ :f }
> :OnFail { "No such file: '$_'" }
> subset Celsius of Num where { $_ >= -273.15 }
>:OnFail { "Celsius temperature should be a Num >= -273.15, not '$_' " }
>
> With something akin to that, developers won't have to write extra
> boilerplate every time a constraint fails. Plus, the code is friendlier :)
>
> Cheers,
> Ovid
> --
> Buy the book - http://www.oreilly.com/catalog/perlhks/
> Tech blog- http://use.perl.org/~Ovid/journal/
> Twitter - http://twitter.com/OvidPerl
> Official Perl 6 Wiki - http://www.perlfoundation.org/perl6
>
>
>
--
John "ash" Harrison
Re: Perl 6 IDEs
http://github.com/petdance/vim-perl has vim syntax highlighting for perl 6. 2009/12/7 Steffen Schwigon > "Víctor A. Rodríguez (Bit-Man)" writes: > > Hi perlsixers, > > > > we've been working a bit on Perl 6 lately [1] and some work, even the > > basic coding, would be great if we use some IDE. > > I'm a regular Eclipse user and EPIC seems the natural choice for me, > > but it doesn't support Perl 6 (yet). Also tied to install Padre on top > > of Ubuntu but just went to nowhere :-P > > > > Did anyone tried any other Perl 6 aware IDE ?? > > There is a Perl6 aware cperl-mode.el for Emacs which works quite ok. > Don't start a war on whether it's an IDE. I just wanted to mention it. > Find it in the Pugs repository. > > Kind regards, > Steffen > -- > Steffen Schwigon > -- John "ash" Harrison
