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 +^= operate
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:
# New Ticket Created by Bernhard Schmalhofer
# Please include the string: [perl #35824]
# in the subject line of all future correspondence about this issue.
# URL: https://rt.perl.org/rt3/Ticket/Display.html?id=35824
This was posted on the perl6-internals list by Jrgen Bmmels:
In the
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 $:
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
support
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
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 private
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, Juerd?
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 -
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 confused
here,
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
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
:
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
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
# New Ticket Created by Ron Blaschke
# Please include the string: [perl #35836]
# in the subject line of all future correspondence about this issue.
# URL: https://rt.perl.org/rt3/Ticket/Display.html?id=35836
Attached patch quotes some paths.
Otherwise Parrot won't built if living below a
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
paranoid
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 not?
Thanks,
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
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 Perl 5.
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...
I believe you
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, and
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 not
: 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
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
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...)
--
31 matches
Mail list logo
