Re: Plethora of operators
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. Is this then ok? [+^=] (@a ; @b ; @c) or [+^=] ([EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]) 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 depends on the context. Such a semicolon list always provides list context to each of its sublists. The following two constructs are structurally indistinguishable: (0..10; 1,2,4; 3) ([0..10], [1,2,3,4], [3]) If not, how then would I use hyper-reduction ops like [+^=] with several arrays? i.e. How do I write @a +^= @b +^= @c using the [+^=] op? -- Markus Laire Jam. 1:5-6
Re: ^method ?
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($foo); always means: $_.method($foo); and $self.method($foo); always means $?SELF.method($foo); The former is consistent with the rest of Perl 6, and the latter is consistent with most of Perl 5 OO code in the wild. My only stance is that, given there is no clearly sexy solution, at least I can take `$self` home to meet my Mom. Perhaps. However, I'm uncomfortable with the idea of $self being automatically assigned, because so far Perl 6 seems to have managed to avoid automatically providing anything in what I've been thinking of as the 'normal' or 'user' namespace. $?SELF looks 'special'. Admittedly it might be nicer if it was $?self, because it still looks 'special'. It's the same kind of thing that makes me wonder why $a and $b in sort was ever considered a good idea. But then perhaps I'm just odd... choosing a name for the invocant yourself if you don't want $?SELF or $_ to be it (although they will be anyway of course) seems to me to be the height of programming sexiness. I like being able to name things myself. The ./method() thing proposed in another thread is pretty cool too, by the way, and largely renders this thread moot. So perhaps I should have replied to that...
[perl #35824] [TODO] Remove .cvsignore files
# 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 current SVN repository are 76 .cvsignore files. In SVN they aren't used any more. SVN uses the property 'svn:ignore' on a directory instead. During the cvs = svn transition the svn:ignore properties were set but in the recent weeks they started to diverge. Currently (r8078) 22 .cvsignore differ from svn:ignore (see attached cvsignore.diff) I think we should remove .cvsignore files entirly. I noticed that .cvsignore is still used in tool/dev/manicheck.pl and Autrius Tang suggested to use 'svn propget svn:ignore' or 'svk propget svn:ignore'. So that's the plan: i. Migrate the changes in .cvsignore file into the svn:ignore property ii. Tell manicheck.pl to query the SVN properties iii. remove the .cvsignore files
Re: ./method
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 $_
Two-character operator -- call on $?SELF
I was very specific about ./ being prefix only. Aligning it with .: is
ugly, because .: can be used infix.
$object.method
$object.:method
given $object {
.method
.:method # !!
}
Either it should do the expected thing, default to $_, or one of .:'s
syntaxes must be made invalid. Don't try to convince me that prefix .:
is an entirely different operator, because it is spelled the same and
does the same thing (call a private method). The only thing that's
different is that its invocant is left out of the code, and when we then
use something that isn't there, we call that a default. And defaults are
always $_, never $?SELF. But that you know.
Anything that begins with a dot looks way too much like the lone dot to
subtly mean something else.
Either infix .: must go away, or prefix .: must operate on $_.
I think infix .: can go, because calling private methods should be
harder anyway. Make that $object.!!(:)method for all I care.
And I think method :name must be very differently spelled, because it
looks like : is part of the name, which makes me want consistency:
$o.private $.private .private ./private
$o.:private $.:private .:private ./:private
Even forcing whitespace between : and name would already solve this:
method : name. It's ugly though.
To be honest, the current fog around private methods, and my not liking
much of the way they work, is pushing me towards good old _private
instead, ignoring the whole wildly special cased colon method thingies.
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
Re: $:attr vs $.:attr
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 \ .var \ ./var \ has $.:var \$obj.:var \ .:var \ ./:var \ See it yet? It's about consistency in the whole scheme, not the clarity of a single element. I'm not sure I see that you changed anything other than changing Old way to Now, Your proposal to Consistent, adding separator characters between the columns, and removing the word Implicit from the last column. I'm still not seeing the problem. Counting down and then right, I read those: $. means attribute; $: means private attribute; $x. means accessor method; $x.: means private accessor method; and so on... I think you're confusing the method glyph . and the attribute glyph, also . in the first and second columns. Consistency would be to make accessor methods use both the attribute and accessor glyphs .., but that would cause at least 4 problems that I can think of, so . is a nice simple thing to do. In the case of private accessor methods, most of those reasons go away, so .: needn't be (and in fact can't be) shortened. All of the details aside, I simply don't see newbies getting all that confused. For starters, there's no particular reason that they would have to use private attributes all that often, and if they did, they don't really EVER have to use accessor methods on them, though style might nudge them in that direction, there's no real impact on scalability the way there is with regular accessors (because every use of the private accessor is local to the class definition). Now, the one place I can see that you should ALWAYS use the private attribute accessors is in roles. Here, it would be essential, as you don't know what the composing class might want to do to that method, so the only place that I see this being a big concern is in roles that have private attributes. Certainly an edge case newbies won't contend with all that often, yes? Note that it's not *implicit* $?SELF. ./ is a prefix operator that calls a method on $?SELF That's picking nits. I know that, but was referring to the implicit use of $?SELF regardless of the syntax one would have to employ in order to use it explicitly.
Why $.?
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 $: everywhere it is mentioned. Luke [1] Well, you don't have to, but you probably would have written it with a $: if you knew about the accessor all along. Stylistically, I don't think it's a good distinction to have, because when there are explicit accessors present, there is no distinction.
Re: S29 Q: Rules for boxed types
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 them. Think about using a SubType somewhere, and you see why. Ok, that makes sense. However, I also fully expected implementations to add an easy optimization of including unboxed equivalents and letting MMD sort it out. And this makes sense too. Thanks Rod!
Re: $:attr vs $.:attr
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 \ Consistent: has $.var \ $obj.var \ .var \ ./var \ has $.:var \$obj.:var \ .:var \ ./:var \ See it yet? It's about consistency in the whole scheme, not the clarity of a single element. I'm not sure I see that you changed anything other than changing Old way to Now, Your proposal to Consistent, adding separator characters between the columns, and removing the word Implicit from the last column. Okay, let's try it differently, then: Now: Declaration ExplicitImplicit $_ $?SELF .| .\ .\ . \ :| .:\ .:\ . :\ Consistent: .\ .\ .\ . \ .:\.:\ .:\ . :\ I think you're confusing the method glyph . and the attribute glyph, also . in the first and second columns. It's the same thing. $.foo installs an accessor *method*. $object.foo calls that method, it doesn't access $object's $.foo directly. Note that it's not *implicit* $?SELF. ./ is a prefix operator that calls a method on $?SELF That's picking nits. In the process of designing something, every single nit must be picked. Don't take it personally. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: Python on parrot
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 uses Sam's python pmc's I've attached the source as it stands now. I'm just an aspiring parrot hacker. I'm sure that there are a lot of things I'm doing wrong or inefficiently. I'm looking for feedback and suggestions for improvement. Please comment. I want to get my patches on top of Sam's initial work imported into the parrot SVN tree. I believe that having the python compiler code in parrots svn tree is imperative to build a python/parrot community. A python compiler in the parrot tree will lead to more widespread exposure to other parrot developers, increased peer review, testing by more people on a greater variety of platforms, etc. Michal could you expound on your thoughts here, they sound interesting. I'm not sure what Kevin meant by self hosted but I've been thinking about this lately, and what we can do today is creating a back-end for the compiler that emits simplified python code in a way that would give us things like continuations (though with some loss of speed) without the need to duplicate the python library. I meant a python to pir translator/compiler written in python. I've looked at the PyPy project. They are doing cool stuff. I would eventually like to use their work to emit optimized pir for python, but they still have work to do. Kevin Sam Ruby wrote: Michal wrote: On Sat, 16 Apr 2005, Sam Ruby wrote: [I hope you don't mind me putting this back on the list - I would prefer that everybody who is interested can follow along and/or participate] Kevin Tew wrote: Sam Ruby wrote: Hey guys, I didn't see this until just now. Kevin Tew wrote: Sam, Just wondering what the status is on python/parrot/pirate/pyrate. These both look outdated. http://www.intertwingly.net/stories/2004/10/05/pyrate.zip http://pirate.versionhost.com/viewcvs.cgi/pirate/ I haven't looked at it for a few months now. I do plan to revisit it enough to get the Pie-thon tests completed by the time of OSCON (in August). Sam, are you still interested in this? I had better be: http://conferences.oreillynet.com/cs/os2005/view/e_sess/6833 Is there a up to date cvs repo? http://pirate.tangentcode.com/ Can we get this code checked into the parrot svn repo? Unfortunately, no. Much of this code is copyright Michal Wallace. The good news is that the good stuff is in the parrot repo already. What is left - a simple translator - can and should, IMHO, be recoded into Perl6 once enough of that is running. - Sam Ruby So why won't Michal Wallace sign over the copyright? I talked to Michal briefly about this a while back. My impression was that he wanted to sign over the copyright to the Python foundation. Which makes a bit of sense - Pirate is based on code created by Andrew Kuchling and the copyright on that work already belongs to the Python foundation. Mostly I think pirate is just a different project from parrot and I don't want to hand over control of which patches to apply, etc. So far, I've never rejected a patch or turned down anyone for cvs access, but I'd like to reserve the right. (Also, Dan and the parrot team had other ideas about how to implement python.) the goal of having everything run on a single runtime does not necessarily imply that everything has to be owned by a single organization and put into a single repository. Yes. That was the other main idea. I was hoping that we could leverage the objects that the python team had already created. Do PMC's still have to be compiled inside the parrot source tree? To me, the problem is that the PMC's are in the parrot tree, not that the compiler isn't in there with it. Parrot (including the build system) is a moving target. Long term, the answer is no. Short term, the answer is yes. My own opinions is that Michal thinks too much. ;-) This is almost certainly true. :) My impression is that everybody here is reasonable, and if it made sense for further development to be transferred to another organization, then some reasonable arrangement would be made. I hope this is true, too. :) Also, I believe that much of the initial work is throwaway work anyway. Build one to throw away, and all that. I've never really bought that logic. :) It works, and (especially after your last batch of refactorings) the code is pretty clean. I would like to see the emitter code separated out into a builder object though. Cool I did notice all the python pmcs. By translator I assume you mean a interpreter/compiler to parrot byte code. At the moment, it is to Python to IMC, but eventually going directly to bytecode would be a good idea. That's fine with me, as long as parrots imc compiler does the work. :) Why would you do it in Perl6, why
Re: Why $.?
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 trait * we basically force people to document the private/public distinction every place they reference $:x -A12 * Prevents access to class variables (e.g. using our) from outside the class. * %$obj notation includes private attributes when inside, but not when outside the class * Private variables use a different dispatcher.
Re: $:attr vs $.:attr
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? I think I've demonstrated that I get it. I just don't agree with your thesis that that one character is a) a problem or b) inconsistent. I think you're confusing the method glyph . and the attribute glyph, also . in the first and second columns. It's the same thing. Well, there's the problem. If you see those as the same symbol, then of course this is deeply confusing. After all, $.foo doesn't behave anything like a method, and yet it uses the method symbol. Try looking at those two symbols as TWO SYMBOLS, and I think your life gets easier. $.foo -- Attribute glyph . used after scalar variable glyph $. $obj.foo -- Method glyph . used after scalar variable. If you de-couple those in your mind, then there's $.foo installs an accessor *method*. Well, it can. It won't if there's already a method there, of course, and that's an important distinction. There's no fundamental tie between the two. The auto-accessor is just a convenience that is placed there for you if you didn't go out of your way to supply one. It's not part of the attribute, and so we should not name the attribute in order to match the naming of the method. If anything, we should do the reverse, but I'm happy with the way it is. $object.foo calls that method, it doesn't access $object's $.foo directly. Yes, that's correct. That's because you're using the method-invocation glyph. If you had used the attribute glyph ($.foo), then you would get direct access. Are you telling me this because you didn't think I knew? It certainly doesn't seem to further the point Note that it's not *implicit* $?SELF. ./ is a prefix operator that calls a method on $?SELF That's picking nits. In the process of designing something, every single nit must be picked. Don't take it personally. You removed the context supplied by my next sentence. Your nit to which I was referring was NOT a design comment, and I still hold that my original usage of implicit is correct.
Re: [perl #35305] [PATCH] skip threads 'detatch' test on win32
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 - P6=PMCNULL,
13 set I3, 2- I3=1,
16 invoke
17 set I5, P2 - I5=0, P2=ParrotThread=PMC(0x7d5a08)
20 getinterp P2 - P2=ParrotThread=PMC(0x7d5a08)
22 find_method P0, P2, detach - P0=NCI=PMC(0x638620), P2=ParrotInterpr
eter=PMC(0x637dc8),
26 invoke
27 defined I0, P6 - I0=1, P6=TQueue=PMC(0x7d59f0)
30 unless I0, -3- I0=0,
27 defined I0, P6 - I0=0, P6=TQueue=PMC(0x7d59f0)
30 unless I0, -3- I0=0,
27 defined I0, P6 - I0=0, P6=TQueue=PMC(0x7d59f0)
30 unless I0, -3- I0=0,
27 defined I0, P6 - I0=0, P6=TQueue=PMC(0x7d59f0)
30 unless I0, -3- I0=0,
27 defined I0, P6 - I0=0, P6=TQueue=PMC(0x7d59f0)
30 unless I0, -3- I0=0,
27 defined I0, P6 - I0=0, P6=TQueue=PMC(0x7d59f0)
30 unless I0, -3- I0=0,
etc
On 5/15/05, Vladimir Lipsky [EMAIL PROTECTED] wrote:
the 'detatch' threads test hangs on win32. this small patch skips one
Could you try the following code('the detatch' threads test with one tweak)
and tell me if it hangs either and what output you get?
find_global P5, _foo
new P2, .ParrotThread
find_method P0, P2, thread3
new P6, .TQueue # need a flag that thread is done
set I3, 2
invoke # start the thread
set I5, P2
getinterp P2
find_method P0, P2, detach
invoke
wait:
defined I0, P6
unless I0, wait
print done\n
sleep 5 # Maybe a race condition?
end
.pcc_sub _foo:
print thread\n
new P2, .Integer
push P6, P2 # push item on queue
returncc
Re: $:attr vs $.:attr
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, you just have an opinion that differs from mine. Please don't take my comments as condescending (especially the ones I type first thing in the morning ;-) -- Aaron Sherman [EMAIL PROTECTED] Senior Systems Engineer and Toolsmith It's the sound of a satellite saying, 'get me down!' -Shriekback
Re: Python on parrot
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 spike of how a pirate refactoring could go, not a call to start a whole new incompatible project. And am working to generate a python to pir translator/compiler that uses Sam's python pmc's I've attached the source as it stands now. I'm just an aspiring parrot hacker. I'm sure that there are a lot of things I'm doing wrong or inefficiently. I'm looking for feedback and suggestions for improvement. Please comment. Well, one thing that's innefficient is to write your own compiler when there are already two mostly working examples out there. I want to get my patches on top of Sam's initial work imported into the parrot SVN tree. I believe that having the python compiler code in parrots svn tree is imperative to build a python/parrot community. I'm absolutely bewildered that you would take that route in order to build a community. Between pie-thon and pirate there already are two python compilers, and pie-thon already *is* in the parrot tree... As far as I can tell, you didn't approach either existing group and see if you could help. You just went off and did your own thing. You're not building a community, you're creating yet another faction. A python compiler in the parrot tree will lead to more widespread exposure to other parrot developers, increased peer review, testing by more people on a greater variety of platforms, etc. This is a great goal, but I'm not sure it follows that having it in the source tree would lead to more exposure. To me, if you want exposure, a much better idea would be to *talk* to people, either on mailing lists or blogs or whatever. In other words, market the project. You need things like documentation and a website. Where the code lives is a fairly trivial concern. It sounds like you just want parrot developers to stumble on to your code in the tree and pitch in. In my mind, the target audience for pirate is python developers (like yourself). People who might have heard about parrot, but don't necessarily know much about it or how it works. But if you can tell all the nice things we get: - this buys us continuations without the genius-level hacks required by stackless - we'll be able to leverage CPAN and code written in other languages... - we'll have a native call interface - (etc) ... then maybe python hackers will be interested. So they should be able to download a python file and run it. The python file should work like every other python file, and leverage the distutils. It should have a setup.py install script and if necessary, a windows installer and rpms. There should be a link to download a binary version of parrot so that the first step isn't to compile a virtual machine they know nothing about - especially if they're developing on windows without a compiler. To me, having the code burried in the middle of the parrot tree is a huge barrier to entry to new developers. Of course if you're targeting parrot developers who may or may not know python, that's another story... But from what I can tell, the other compilers in the parrot svn tree just aren't getting the kind of exposure you're talking about. I don't know, maybe I'm just rambling, but I don't see how putting the source in the parrot repository is either necessary or sufficient for widespread exposure. :/ Michal could you expound on your thoughts here, they sound interesting. I'm not sure what Kevin meant by self hosted but I've been thinking about this lately, and what we can do today is creating a back-end for the compiler that emits simplified python code in a way that would give us things like continuations (though with some loss of speed) without the need to duplicate the python library. Sure. This is kind of off topic for the parrot list. I posted a blog entry here: http://sabren.com/index.php?p=62 I meant a python to pir translator/compiler written in python. Like this one: http://pirate.tangentcode.com/ ?? I've looked at the PyPy project. They are doing cool stuff. I would eventually like to use their work to emit optimized pir for python, but they still have work to do. So why don't you want to help them with that work? Right now you're just reinventing the wheel. If you were writing a backend for pypy, that would be one thing. That would actually be useful. Better yet, not write up a little report about what it would take to get pirate to work with pypy? We could almost certainly leverage their type inference engine. I'd love to see pirate become just another backend for pypy. It seems to me that would do a lot more to build community than the approach you're taking. - Michal http://withoutane.com/
Re: Plethora of operators
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 : depends on the context. Such a semicolon list always provides list : context to each of its sublists. The following two constructs are : structurally indistinguishable: : : (0..10; 1,2,4; 3) : ([0..10], [1,2,3,4], [3]) By the way, S09 is wrong there. Semicolon no longer forces retroactive extra-listhood unless the context it's bound to specifically requests it. : If not, how then would I use hyper-reduction ops like [+^=] with : several arrays? : : i.e. How do I write : : @a +^= @b +^= @c : : using the [+^=] op? Possibly [...] always supplies [EMAIL PROTECTED] is context(Scalar), since hypers are essentially scalar context on both sides, and we do have the is context(Scalar) concept floating around vaguely. Though in this case it almost feels more like a macro argument than a scalar. Larry
BUILD and other submethods
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 directly to the current class, but the default implementation of
new (as given by Object), calls BUILDALL, which in turn calls all BUILDs, so
I think both BUILDs are executed. Are they?
S12 says that [s]ubmethods are for declaring infrastructural methods that
shouldn't be inherited by subclasses. I read this shouldn't be inherited as
that a submethod definition of the same name in a subclass does not
overwrite/substitute the definition of the parent class. Correct?
class A { submethod blarb() { say 42 } }
class B is A { submethod blarb() { say 23 } }
B.new.blarb;
Does this only output 23? (I think so, as I don't call A::blarb explicitly.
If I wanted to call A's blarb, I'd have to say B.new.A::blarb, correct?)
--Ingo
/lots_of_questions
--
Linux, the choice of a GNU | self-reference, n. - See self-reference
generation on a dual AMD |
Athlon!|
Roles and BUILD
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;
}
...;
}
role IRC::Bot::JoinOnInvite {
submethod BUILD() {
./add_handler(INVITE, - Str $channel {
./join($channel);
});
}
}
role IRC::Bot::SayHelloOnJoin {
submethod BUILD() {
./add_handler(JOIN, - Str $nick {
./msg($nick, Hi $nick!);
});
}
}
class MyBot {
is IRC::Bot;
does IRC::Bot::JoinOnInvite;
does IRC::Bot::SayHelloOnJoin;
}
my MyBot $bot .= new;
# Are IRC::Bot::JoinOnInvite::BUILD and
# IRC::Bot::SayHelloOnJoin::BUILD called?
And:
my IRC::Bot $bot .= new;
# Up to now, no BUILDs of any role is called.
$bot does IRC::Bot::SayHelloOnJoin;
# Is IRC::Bot::SayHelloOnJoin's BUILD called now?
--Ingo
--
Linux, the choice of a GNU | To understand recursion, you must first
generation on a dual AMD | understand recursion.
Athlon!|
Re: BUILD and other submethods
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 output:
: 42
: 23
:
: S12 says that submethod[s] [are] called only when a method call is
: dispatched directly to the current class, but the default implementation of
: new (as given by Object), calls BUILDALL, which in turn calls all BUILDs,
so
: I think both BUILDs are executed. Are they?
Yes.
: S12 says that [s]ubmethods are for declaring infrastructural methods that
: shouldn't be inherited by subclasses. I read this shouldn't be inherited
as
: that a submethod definition of the same name in a subclass does not
: overwrite/substitute the definition of the parent class. Correct?
Correct.
: class A { submethod blarb() { say 42 } }
: class B is A { submethod blarb() { say 23 } }
: B.new.blarb;
:
: Does this only output 23? (I think so, as I don't call A::blarb explicitly.
: If I wanted to call A's blarb, I'd have to say B.new.A::blarb, correct?)
Yes.
Larry
Re: Roles and BUILD
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 the appropriate time). : And: : my IRC::Bot $bot .= new; : # Up to now, no BUILDs of any role is called. : $bot does IRC::Bot::SayHelloOnJoin; : # Is IRC::Bot::SayHelloOnJoin's BUILD called now? Seems like a reasonable thing in general. If you're going to be adding state to an object, it really ought to be initialized correctly (though in this case you seem to be adding the state outside the object itself, which is also fine). Larry
[perl #35836] [PATCH] Dynclasses make pathquote
# 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 directory containing spaces (eg C:/Documents and Settings). Ron dynclasses_make_pathquote.patch Description: Binary data
Re: [perl #35836] [PATCH] Dynclasses make pathquote
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
Re: [perl #35836] [PATCH] Dynclasses make pathquote
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 today. Never thought about this, but quite likely, yes. On the other hand, I don't know how quotes would be escaped, to create such a directory in first place. I guess is one of the characters that shouldn't be used anywhere in a path, like * | or . Ron
not 4,3,2,1,0;
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, /Autrijus/ pgpT7OdpADCYf.pgp Description: PGP signature
Re: ^method ?
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 optional on function calls... This symmetry and regularity seems like a powerful thing to me and I would not want to lose it... Matt -- Computer Science is merely the post-Turing Decline of Formal Systems Theory. -???
Re: ^method ?
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. :) In Perl 6, foo is a reference to the function foo, and never a call. That makes it symmetric with the other $.foo notations. Matt -- wolverian signature.asc Description: Digital signature
Re: ^method ?
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 are thinking in Perl 5. :) In Perl 6, foo is a
reference to the function foo, and never a call. That makes it
symmetric with the other $.foo notations.
yes, but with parens, it *is* a call:
sub foo(...) {...}
say foo(...); # Calls foo
say foo(...); # Calls foo
say foo; # CODE(0x) or somesuch
(FWIW, I agree with Matt, but Juerd's ./method is nice, too. And we
shouldn't forget that Perl 6's OO is *far* more than that method on
self thing. I favour .method meaning $?SELF.method, but this only a
very minor issue when comparing with roles, autogenerated accessors,
anonymous roles|classes, parameterized roles, etc. :))
--Ingo
--
Linux, the choice of a GNU | The next statement is not true. The
generation on a dual AMD | previous statement is true.
Athlon!|
Re: not 4,3,2,1,0;
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 to this behaviour? There is none. Wherever Perl 5 defaults to last of list, Perl 6 doesn't. If you wanted to emulate it in user code, you'd have is context(Scalar) or some such and then explicitly ignore all but the last value in your implementation. But no built-ins rely on C-comma behavior. : Also, is this still sane for Perl 6's not? No. In list context it should do !«[4,3,2,1,0]. In scalar context it should probably return something like !any(4,3,2,1,0) or none(4,3,2,1,0) or whatever we decide makes our collective brain hurt the least. Larry
Re: not 4,3,2,1,0;
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 return its negation. : : What is the Perl 6 signature that correspond to this behaviour? There is none. Wherever Perl 5 defaults to last of list, Perl 6 doesn't. If you wanted to emulate it in user code, you'd have is context(Scalar) or some such and then explicitly ignore all but the last value in your implementation. But no built-ins rely on C-comma behavior. 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 something like: multi sub not (Bool $x1) multi sub not (Bool $x1, Bool $x2) multi sub not (Bool $x1, Bool $x2, Bool $x3) ... But I'm not sure about how to express it in one line. No. In list context it should do !4,3,2,1,0]. In scalar context it should probably return something like !any(4,3,2,1,0) or none(4,3,2,1,0) or whatever we decide makes our collective brain hurt the least. IMHO, having not($x, $y, $z) simply mean !(any($x, $y, $z)) is easiest to explain. Thanks, /Autrijus/ pgpXSnBqnusTt.pgp Description: PGP signature
Re: not 4,3,2,1,0;
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 something like: : : multi sub not (Bool $x1) : multi sub not (Bool $x1, Bool $x2) : multi sub not (Bool $x1, Bool $x2, Bool $x3) : ... : : But I'm not sure about how to express it in one line. That's sub not (*args is context(Scalar)) or whatever we end up calling the Any/Scalar type. Larry
[PATCH] more ws.t tests, fixed
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/Linux http://www.debian.orgIndex: t/p6rules/ws.t
===
--- t/p6rules/ws.t (revision 8109)
+++ t/p6rules/ws.t (working copy)
@@ -1,6 +1,6 @@
use strict;
use warnings;
-use Parrot::Test tests = 15;
+use Parrot::Test tests = 17;
use Parrot::Test::PGE;
@@ -23,6 +23,15 @@
p6rule_is ('foo-bar', ':w foo -? bar', 'basic ws match \s* \s*');
p6rule_isnt('foobar', ':w foo -? bar', 'basic ws non-match');
+# with :w not separated by a space
+# XXX: These forms of modifier separation do not yet work
+#p6rule_is ('foo - bar', ':w()foo -? bar', 'basic ws match');
+#p6rule_is ('foo - bar', ':w[]foo -? bar', 'basic ws match');
+p6rule_is ('foo - bar', ':w\bfoo -? bar',
+'basic ws match with boundary modifier separation');
+p6rule_is ('foo - bar', ':w::foo -? bar',
+'basic ws match with backtrack no-op modifier separation');
+
# XXX: When available, add tests for full form :words modifier
-# dont forget to change the number of tests :-)
+# Don't forget to change the number of tests :-)
Re: Roles and BUILD
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...) -- Brent 'Dax' Royal-Gordon [EMAIL PROTECTED] Perl and Parrot hacker
