On Mon, May 16, 2005 at 04:06:15PM -0700, Larry Wall wrote:
> That's
>
> sub not (*args is context(Scalar))
>
> or whatever we end up calling the Any/Scalar type.
How about is context(Item) versus is context(Slurpy). :)
Also, shouldn't the *args there be [EMAIL PROTECTED] Is it really okay
On 5/16/05, Larry Wall <[EMAIL PROTECTED]> wrote:
> Yes, role BUILD submethods are magically composed into the class's
> BUILD method somehow (or at least called at the appropriate time).
Could this be a feature of all submethods, not just BUILD? (DESTROY,
for instance, would need it too...)
--
I left something uncommented in my prior patch, causing failure. Fixed.
This is additional tests for :w using (), [], \b and :: for separation.
-Dino
--
.~.Dino Morelli
/V\email: [EMAIL PROTECTED]
/( )\ weblog: http://categorically.net/d/blog/
^^-^^ preferred distro: Debian GNU/Li
Ingo Blechschmidt skribis 2005-05-16 21:28 (+0200):
> yes, but with parens, it *is* a call:
> sub foo(...) {...}
> say &foo(...); # Calls &foo
> say foo(...); # Calls &foo
> say &foo; # "CODE(0x)" or somesuch
Only because there's an implicit "." there. This is like
On Tue, May 17, 2005 at 05:32:27AM +0800, Autrijus Tang wrote:
: Ok, but I'm still not too sure about what signature will Perl 6's ¬
: have, that can impose singular context on each of its argument (so that
: not(@foo) won't flatten), but still accept an unlimited number of
: arguments. It's somet
On Mon, May 16, 2005 at 12:49:13PM -0700, Larry Wall wrote:
> On Tue, May 17, 2005 at 01:48:20AM +0800, Autrijus Tang wrote:
> : This evaluates to 1 in Perl 5:
> :
> : not 4,3,2,1,0;
> :
> : Namely, the "not" listOp is taking the last of a variadic, non-slurpy
> : argument list, boolify it,
On Tue, May 17, 2005 at 01:48:20AM +0800, Autrijus Tang wrote:
: This evaluates to 1 in Perl 5:
:
: not 4,3,2,1,0;
:
: Namely, the "not" listOp is taking the last of a variadic, non-slurpy
: argument list, boolify it, and return its negation.
:
: What is the Perl 6 signature that correspond
Hi,
wolverian wrote:
> On Mon, May 16, 2005 at 02:26:02PM -0400, Matt Fowles wrote:
>> $.foo
>> @.foo
>> %.foo
>>
>> and their ilk operate on the current invocant, $?SELF. This leads
>> naturally toward &.foo also refering to $?SELF. But as we all know
>> the & is optional on function calls...
On Mon, May 16, 2005 at 02:26:02PM -0400, Matt Fowles wrote:
> $.foo
> @.foo
> %.foo
>
> and their ilk operate on the current invocant, $?SELF. This leads
> naturally toward &.foo also refering to $?SELF. But as we all know
> the & is optional on function calls...
I believe you are thinking in
All~
I feel like people have lost track of one of the initial arguments for
having C< .method == $?SELF.method >. Currently, all of
$.foo
@.foo
%.foo
and their ilk operate on the current invocant, $?SELF. This leads
naturally toward &.foo also refering to $?SELF. But as we all know
the & is o
chromatic wrote:
> On Mon, 2005-05-16 at 09:58 -0700, Ron Blaschke wrote:
>> Attached patch quotes some paths.
>> Otherwise Parrot won't built if living below a directory containing
>> spaces (eg "C:/Documents and Settings").
> Will this have problems if a directory name contains quotes? I feel
This evaluates to 1 in Perl 5:
not 4,3,2,1,0;
Namely, the "not" listOp is taking the last of a variadic, non-slurpy
argument list, boolify it, and return its negation.
What is the Perl 6 signature that correspond to this behaviour?
Also, is this still sane for Perl 6's ¬?
Thanks,
/Autriju
On Mon, 2005-05-16 at 09:58 -0700, Ron Blaschke wrote:
> Attached patch quotes some paths.
>
> Otherwise Parrot won't built if living below a directory containing
> spaces (eg "C:/Documents and Settings").
Will this have problems if a directory name contains quotes? I feel
paranoid today.
-- c
# New Ticket Created by Ron Blaschke
# Please include the string: [perl #35836]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/rt3/Ticket/Display.html?id=35836 >
Attached patch quotes some paths.
Otherwise Parrot won't built if living below a direc
On Mon, May 16, 2005 at 03:10:10PM +, Ingo Blechschmidt wrote:
: my MyBot $bot .= new;
: # Are IRC::Bot::JoinOnInvite::BUILD and
: # IRC::Bot::SayHelloOnJoin::BUILD called?
Yes, role BUILD submethods are magically composed into the class's
BUILD method somehow (or at least called at t
On Mon, 2005-05-16 at 07:21, Aaron Sherman wrote:
> * %$obj notation includes private attributes when inside, but not
> when outside the class
This bit was new to me this morning, when I looked it up, and I'd like
to delve into a bit more.
If the idea is to provide a hash-like thin
On Mon, May 16, 2005 at 02:59:11PM +, Ingo Blechschmidt wrote:
: Hi,
:
: class Foo {
: submethod BUILD() {
: say 42;
: }
: }
:
: class Bar is Foo {
: submethod BUILD() {
: say 23;
: }
: }
:
: my Bar $bar .= new;
:
: I suppose this will o
Hi,
are Roles allowed to contain submethods and does especially the BUILD
submethod
work as I presume in the following code?
class IRC::Bot {
has Array %:handler;
method add_handler(Str $event, Code $callback) {
push %:handler{$event}: $callback;
}
...;
}
Hi,
class Foo {
submethod BUILD() {
say 42;
}
}
class Bar is Foo {
submethod BUILD() {
say 23;
}
}
my Bar $bar .= new;
I suppose this will output:
42
23
S12 says that "submethod[s] [are] called only when a method call is
dispatched
On Mon, May 16, 2005 at 10:18:47AM +0300, Markus Laire wrote:
: As S09 says that:
:
: At the statement level, a semicolon terminates the current
: expression. Within any kind of bracketing construct, semicolon
: notionally produces a list of lists, the interpretation of which
: dep
On Sun, 15 May 2005, Kevin Tew wrote:
I've taken the code from
http://www.intertwingly.net/stories/2004/10/05/pyrate.zip,
which I assume to be Sam's code. It was basically stubs
with a few AST nodes implemented when I started with it.
Er. Yes. I can't speak for Sam, but I interpreted his post
as a
On Mon, 2005-05-16 at 09:08, Aaron Sherman wrote:
> Well, there's the problem. If you see those as the same symbol, then of
> course this is deeply confusing.
I just want to make the point that the "you" in that sentence is "you,
the user of Perl", not "you, Juerd". Obviously, you are not confuse
parrot (r8016): no change. hangs w/98% cpu. here's the -t output:
>parrot -t test_b.pasm
0 find_global P5, "_foo" - P5=SArray=PMC(0x7d5a50),
3 new P2, 18 - P2=PMCNULL,
6 find_method P0, P2, "thread3"- P0=PMCNULL,
P2=ParrotThread=PMC(0x7d5a08),
10 new P6, 54 - P
On Mon, 2005-05-16 at 12:23 +0200, Juerd wrote:
> Aaron Sherman skribis 2005-05-16 5:54 (-0400):
> > I'm not sure I see that you changed anything
[...]
> Okay, let's try it differently, then:
[...something that looks like braille...]
And now, you've s/[\$\w]+//g; what point are you making, Jue
On Mon, 2005-05-16 at 04:02 -0600, Luke Palmer wrote:
> I am currently failing to see the need for a distinction between $.
> and $: . The only difference is in whether accessors are *generated*;
Not at all! There are numerous differences as described in A12:
* The attribute gets a "privat
Re: Pyrate( Sam's stub code )
I've taken the code from
http://www.intertwingly.net/stories/2004/10/05/pyrate.zip, which I
assume to be Sam's code.
It was basically stubs with a few AST nodes implemented when I started
with it.
And am working to generate a python to pir translator/compiler that u
Aaron Sherman skribis 2005-05-16 5:54 (-0400):
> On Sun, 2005-05-15 at 19:18 +0200, Juerd wrote:
> > Now:
> > Declaration ExplicitImplicit $_ $?SELF
> > has $.var | $obj.var \ .var \ ./var \
> > has $:var | $obj.:var \ .:var \ ./:var \
On Sun, 2005-05-15 at 13:33 -0500, Rod Adams wrote:
> Aaron Sherman wrote:
>
> >In reviewing S29 as it stands now, I see that many builtins both receive
> >and return boxed basic types.
> My thoughts on writing it were:
>
> The boxed version is the specification, in that the language must
> sup
I am currently failing to see the need for a distinction between $.
and $: . The only difference is in whether accessors are *generated*;
the attribute access itself is no different. If you want to refactor
and turn your auto-accessor into a custom one, you have to[1] go
replace $. with $: everyw
On Sun, 2005-05-15 at 19:18 +0200, Juerd wrote:
> Now:
> Declaration ExplicitImplicit $_ $?SELF
> has $.var | $obj.var \ .var \ ./var \
> has $:var | $obj.:var \ .:var \ ./:var \
>
> Consistent:
> has $.var \ $obj.var \
Damian Conway skribis 2005-05-16 10:33 (+1000):
> This missing design rationale here is that the colon acts as part of the
> unary operator:
> ./unary public-method-call-on-invocant
> .:unary private-method-call-on-invocant
> So the rule is:
> One-character operator --> call on
# New Ticket Created by Bernhard Schmalhofer
# Please include the string: [perl #35824]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/rt3/Ticket/Display.html?id=35824 >
This was posted on the perl6-internals list by JÃrgen BÃmmels:
> In the curren
> On 15/05/05 22:48 +0100, Matthew Walton wrote:
> I don't think that is what Rob is saying at all.
It wasn't aimed entirely at Rob. I have a bad habit on mailing lists of
vaguely replying to the entire thread without remembering who said what
and being too lazy to check.
> My read:
>
>.method
Juerd wrote:
Juerd skribis 2005-05-14 17:23 (+0200):
Markus Laire skribis 2005-05-14 18:07 (+0300):
[>>+^=<<] (@a, @b, @c)
These arrays flatten first (otherwise [+] @foo could never calculate the
sum of the elements), so imagine that you have
$foo, $bar, $baz, $quux, $xyzzy
to let >>+^=<< op
34 matches
Mail list logo
