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
> 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
# 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
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
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 \
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 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
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 \
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
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
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
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 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
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, 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
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
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;
}
...;
}
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
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 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
# 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, 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
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
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
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
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 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
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 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
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
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
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...)
--
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
34 matches
Mail list logo
