Re: Scalability of Devel::Cover
On Jun 14, 2005, at 1:32 PM, Kevin Scaldeferri wrote: A little more interesting information. I ran a coverage test for the full code base. Then I did this: [kevin]% time perl -MDevel::Cover -e 1 ... perl -MDevel::Cover -e 1 14.19s user 0.88s system 79% cpu 18.997 total After spending a little time reading the code, I tried simply commenting out line 582 of Devel/Cover.pm: #$Structure-read_all; This brought the above test down to about 6 seconds instead, which is still 4.5 seconds longer than when no coverage database is present at all, but a substantial improvement, none-the-less. Unfortunately, this change seems to make eval_use.t barf badly and I am out of time to work on this for today. Here's a subset of the failures: t/eval_use..ok 29/80# Test 30 got: '14 4100 if ($x) { eval 'use E2' } ' (/home/kevin/.cpan/build/Devel-Cover-0.53/blib/lib/Devel/Cover/Test.pm at line 277 fail #30) t/eval_use..NOK 30#Expected: '14 4100 100 if ($x) { eval 'use E2' } ' t/eval_use..ok 31/80# Test 32 got: '15 4 print 3 - $x\n; ' (/home/kevin/.cpan/build/Devel-Cover-0.53/blib/lib/Devel/Cover/Test.pm at line 277 fail #32) #Expected: ' 2 ' t/eval_use..NOK 32# Test 33 got: '16 4100 100 if ($x 4) { eval 'use E3' } ' (/home/kevin/.cpan/build/Devel-Cover-0.53/blib/lib/Devel/Cover/Test.pm at line 277 fail #33) #Expected: ' 2 ' t/eval_use..ok 34/80# Test 35 got: ' 4 ' (/home/kevin/.cpan/build/Devel-Cover-0.53/blib/lib/Devel/Cover/Test.pm at line 277 fail #35) #Expected: '15 4print 3 - $x\n; ' ... Failed Test Stat Wstat Total Fail Failed List of Failed --- t/eval_use.t 80 45 56.25% 30 32-33 35-42 44-48 50-58 60-68 70-80 1 subtest skipped. Failed 1/34 test scripts, 97.06% okay. 45/3180 subtests failed, 98.58% okay. -kevin
Re: Adding methods to (existing) classes
Patrick R. Michaud wrote: ... I.e., I'd like to be able to do something along the lines of: .sub main @MAIN $P99 = newclass Foo $S0 = .sub h @ANON\nprint \Hello\\n.end\n $P0 = compreg PIR $P1 = compile $P0, $S0 store_global Foo, hello, $P1 $I2 = findclass Foo $P2 = new $I2 $P2.hello() .end That works fine if you s/findclass/find_type/ Cfindclass is one of the ugly/evil/wrong opcode warts that will be removed soon. It duplicates the functionality of Cfind_type with restricted usage (returns a *boolean*) and inconsistent syntax. leo
Re: new mailing list: perl6-general?
Hi, I think, that David's version is matches with my opinion. I don't think, that beginners would be a better name for it, but maybe more practical, as it's a more evident name. Bye, Andras David Storrs wrote: On Jun 15, 2005, at 3:33 PM, Patrick R. Michaud wrote: And here they are... this is just a draft -- feel free to flame/edit/ tear it apart liberally. These are also written assuming we don't create a perl6-general list (but it shouldn't be hard to adapt them should one be created). Well, I'd suggest the following. (Anything not mentioned stays as you wrote it.) perl6-language This is the theory of list. Discussion of the design of the perl6 language, and its desired (or unwanted) feature list. If you have patches and/or suggestions for improving the Perl 6 design documents (Apocalypses, Synopses, etc.), send them here. perl6-howto This is the practice of list. Come here to ask How do I..., What does XYZ mean?, or Why doesn't this work? Novices are especially welcome. (Note: I envision this list being much like beginners@perl.org, but I never liked that name because it seems like it would drive away those who have a question but do not consider themselves beginners. On the other hand, maybe it's more important to explicitly welcome novices. I could go either way: maybe the above list should be 'perl6-beginners')
Re: new mailing list: perl6-general?
Hi, Hi, I think, that David's version is matches with my opinion. I don't think, that beginners would be a better name for it, but maybe more practical, as it's a more evident name. Hmmm, I think beginner is a little negative. What about professional Perl5 programmers, who wish to learn Perl6? Wouldn't like the name :-)) How about 'perl6-usage', 'perl6-programming' or... hmmm, simply 'perl6'? - Fagzal
Re: new mailing list: perl6-general?
Hi, Fagyal Csongor wrote: I think, that David's version is matches with my opinion. I don't think, that beginners would be a better name for it, but maybe more practical, as it's a more evident name. Hmmm, I think beginner is a little negative. What about professional Perl5 programmers, who wish to learn Perl6? Wouldn't like the name :-)) How about 'perl6-usage', 'perl6-programming' or... hmmm, simply 'perl6'? I like perl6-programming, as it means, that it's ok to post there general programming questions (related to perl6), too. And maybe my original proposal, perl6-general is OK, too. Bye, Andras
sub my_zip (...?) {}
Currently in Pugs *zip has no signature -- it simply rewrites its arguments into the listfix (i.e. Y) function. That is bad because it can't be introspected, and you can't define something like that yourself. It also makes it uncompilable to Parrot as I don't control the runloop there. :) Also, currently the following code does not flatten @a and @b together, which I'm not exactly sure is correct or not: zip(@a, @b); What should zip's function signature be, if I want to do something like zip() that handles semicolon lists? Thanks, /Autrijus/ pgphoonut2HTQ.pgp Description: PGP signature
Re: New generational GC Scheme
Sorry for answering so late... On 6/8/05, Leopold Toetsch [EMAIL PROTECTED] wrote: jerry gay wrote: i'm no gc expert, but here's my comments after discussions with alexandre on #parrot. On 6/8/05, Alexandre Buisse [EMAIL PROTECTED] wrote: since threading issues haven't been mentioned here, i thought i'd make sure they get discussed. now, if someone could say something intelligent about threading issues with this gc scheme, we can start the discussion :-) A thread has typically some objects in it's local memory arena and may refer to shared objects, located in some other arena. We now have two cases: 1) a local GC run in the threads arena 2) GC of the shared arena Case 1) is simple as it's fully private to the thread. A non-shared object can not be referenced by a shared one, therefore all local garbage can be identified. Does that mean that we have a gc structure in each arena (which, as far as I understand parrot design, is similar to a process memory space) ? Or is a gc rather attached to a thread or a shared arena ? (My question could be restated in : are we sure that a thread only uses one arena for its local storage ?). For the shared case 2) things get more complicated. Something like this might happen: - a global GC start event is triggered - all threads must meet at a rendevous point - all threads start a mark phase, shared items are marked either inside a mutex lock or faster with an atomic BTS or CAS [1] - threads can continue to run code or run a private GC too (as the mark is already done) - the owner of the shared arena waits for all threads to finish mark - the owner of the shared arena collects garbage This seems the simplest way to perform it. I am not sure I understand why threads must meet at a rendezvous point, though. Couldn't they just stop what they were doing, mark their shared items and go on ? There is also something else about the locks (but it may be what you call BTS or CAS) : it is the gc of the owner of the arena that should have all the locks, and release them when he's done with the compaction phase (because we know objects won't move anymore). And then we'd need all the threads to meet at a rendezvous point, but only _after_ the marking phase. They wait for the gc to have said I have all the locks and then go on. Of course, if they want access of the objects before the gc is done, they will have to sleep, which makes this part really critical for the system speed and safety. We then use a generational, incremental mark-and-sweep algorithm, such as described by http://citeseer.csail.mit.edu/armstrong95one.html We have different generations (in fact queues) of objects, from 1 to n-1 (the value of n could be tuned dynamically). We also have two tuned dynamically, as in at run-time? alexandre mentioned this may be possible on #parrot, but there may be trouble with decreasing the generation count. i don't know if run-time tuning of the generation count is necessary, but if so, i imagine that decreasing the count at run-time could be achieved by merging generations. Yep. We'd have usually 3 generations: constant / old / new. But if a scope emit's code that it need timely destruction it seems best to just make this scope one generation. On scope exit all remaining objects get merged with the previous generation. I was thinking about the possible advantages of using more generations. One could be that it allows more fine-tuning of memory we allocate. I think we won't be malloc/freeing our generations all the time, but only malloc the overhead when needed, and never free it. If we want the generation to be a whole, we have to copy everything in it (which costs much), if not, we have an array splitted in many parts, which can be imho better described by several generations. So allocating more space is adding a generation. And if we see that we have many empty generations, we can just delete them and free the unused memory. if this gc is tunable at build-time, it should be configurable such that timely destruction can be disabled. after all, most languages just don't need it, so why should they have the overhead? You don't disable timely destruction. In the absence of some special scope_enter / scope_exit opcodes, there is no timely destruction. It only depends on the code that parrot executes. good start! and since the gc is modular, it should be straightforward to implement this without affecting the existing gc--that should make it easier to develop and test. At the beginning GC is modular, yes. But if this concepts works and works fast, then we have the opportunity to use variable-sized PMC bodies. This simplifies e.g. objects vastly. An object is then just an attribute count + a fixed sized piece of memory w/o any indirection (plus the usual PMC stuff). I will begin to dig into parrot source, and hope I will be able to start coding soon, if everyone is ok with the current design.
Hackathon days 4+5
Share Enjoy: http://use.perl.org/~chip/journal/25234 If only use.perl didn't make me compose my HTML in a window about two inches square, it'd be great. OK, I could compose and cutpaste, but where's the fun in that? -- Chip Salzenberg [EMAIL PROTECTED]
Re: sub my_zip (...?) {}
On Thu, Jun 16, 2005 at 05:40:31PM +0800, Autrijus Tang wrote: : Currently in Pugs *zip has no signature -- it simply rewrites its : arguments into the listfix (i.e. Y) function. : : That is bad because it can't be introspected, and you can't define : something like that yourself. It also makes it uncompilable to Parrot : as I don't control the runloop there. :) I think something like sub zip (Pipe [EMAIL PROTECTED]) {...} is probably sufficient. The semicolon operator no longer builds a list of lists, but a list of pipes, which are specially marked Lazies that know they came from pipe operators (including semicolons as a kind of pipe operator). When bound to an ordinary splat array (or in fact any splat array whose type isn't Pipe), the Pipes flatten as if they were comma separated. When bound to an array of type Pipe, each pipe stays discrete. : Also, currently the following code does not flatten @a and @b together, : which I'm not exactly sure is correct or not: : : zip(@a, @b); That should flatten into a single slice/pipe, so zip should probably have the option of complaining about it somehow. On the other hand, you don't want warnings for the default on any such binding, since subscripts use the same binding, and we'll often have subscripts with a single slice. We also have this construct to allow indirect semicolon lists: zip( [;] @lists ) (The [;] reduction operator takes the place of semi in S09.) This does imply that we can pipe into a subscript somehow. If we choose something like () for our placeholder meaning pipe into this location, then @[EMAIL PROTECTED]; @b; @c] is the same as @foo[()] == @a == @b == @c or @c == @foo[()] == @a == @b or @c == (@b == @foo[()] == @a ) or @c == (@b == (@a == @foo[()] ) ) though perhaps there's some ambiguity problems with using a single () as the target of multiple ==. Note that every list has an implied () at the end, which is the default target of pipe operators. That says to me that we probably make a rule that == binds to the leftmost () it sees (if it sees one), so we can differentiate @a == @foo[$x].print() from @a == @foo[()].print And in the absence of an explicit (), the rightmost implicit () is the target, so @a == @foo[$x].print should feed the pipe to the print, not the subscript, even though $x is officially part of a one-element slice with an implicit () at the end. I think this is closest to what people will expect. Larry
Ignoring parameters
Say I have a class method in FooClass, callable as FooClass.greet(): method greet(Class $class: ) { say Hello, FooClass!; } AFAIK, this is the only signature that would work for making greet a class method; but note that I'm not using $class, and I'd expect the compiler to issue a warning in such a case. The same problem exists with methods in classes fulfilling a role, but which want to ignore a parameter in a required method. What do you say about this proposed syntax? method greet(Class undef: ) { ... } # the interface calls for a floor as 1st arg method bereaucracy(Int undef, Int $office_number) { ... } I'm not sure how this works for named fields, but for positional ones it should do well, and is similar to ($a, undef, $c) = LIST syntax. -- Gaal Yahas [EMAIL PROTECTED] http://gaal.livejournal.com/
Re: sub my_zip (...?) {}
[Sent off-group by mistake. On #perl6 the impression was that now Pipe is becoming a Role for things that can lazily be read from; and thus any filehandle or lazy list fulfills them. Larry, please help us understand if this is the case.] On Thu, Jun 16, 2005 at 08:53:41AM -0700, Larry Wall wrote: The semicolon operator no longer builds a list of lists, but a list of pipes, which are specially marked Lazies that know they came from pipe operators (including semicolons as a kind of pipe operator). When bound to an ordinary splat array (or in fact any splat array whose type isn't Pipe), the Pipes flatten as if they were comma separated. When bound to an array of type Pipe, each pipe stays discrete. I thought the class Pipe was reserved for what the result of open-foo| is in Perl 5? That's what we call it in Prelude.pm at least; if it needs to be renamed maybe IPC could work. -- Gaal Yahas [EMAIL PROTECTED] http://gaal.livejournal.com/
Re: sub my_zip (...?) {}
Larry Wall writes: This does imply that we can pipe into a subscript somehow. Why? Or rather, why is that desirable? If we choose something like () for our placeholder meaning pipe into this location, then @[EMAIL PROTECTED]; @b; @c] is the same as @foo[()] == @a == @b == @c That placeholder just looks to me like it's asking for people to be confused by action at a distance. Under what circumstances does using the latter, with n pipes, give an advantage over the former, with n semicolons? Especially given: though perhaps there's some ambiguity problems with using a single () as the target of multiple ==. Note that every list has an implied () at the end, which is the default target of pipe operators. That says to me that we probably make a rule that == binds to the leftmost () it sees (if it sees one) ... And in the absence of an explicit (), the rightmost implicit () is the target That seems to be a lot of rule to remember for some relatively obscure feature, and it's giving a non-intuitive amount of meaning to the innocent-looking empty list (). I think this is closest to what people will expect. Hmmm. I'm not convinced that many people would expect being able to pipe into subscripts at all. Except that you've almost certainly thought about this more than I have, and you are rather good at this language design lark -- so I'm also not convinced by my own criticism of this feature ... Smylers
Re: sub my_zip (...?) {}
On Thu, Jun 16, 2005 at 07:24:42PM +0300, Gaal Yahas wrote: : [Sent off-group by mistake. On #perl6 the impression was that now Pipe : is becoming a Role for things that can lazily be read from; and thus any : filehandle or lazy list fulfills them. Larry, please help us understand : if this is the case.] That's perhaps an overgeneralization. I don't care if there's a special Pipe type or role, as long as there's some declaration for binding that can determine the *syntactic* intent of the caller to do something with multi-dimensional lazy lists, which implies there's some kind of mark to convey that syntactic intent. If it is a role, it's probably only applied to lazy containers implicitly by the calling code. In fact, the actual data structure to be bound to the slurpy is probably a Lazy of Lazys, but we want to avoid two problems here by marking that structure as special. We don't want to accidentally bind a Lazy of Lazys to the slurpy array merely because the next parameter of the list accidentally happens to be one. The intent to use semicolon or pipes has to be there syntactically to get the special multidimensional mark. In @[EMAIL PROTECTED], @bar is always a one-dimensional slice, even if it happens to be lazy. You must specify @foo[[;[EMAIL PROTECTED] or @foo[()] == @bar to get the special mark. On the receiving end, we want to avoid the problem of feeding multidimensional lists to parameters that are expecting flat lists. So the default is that all the pipes into an ordinary slurpy flatten, as if all the semicolon boundaries were actually commas. But for those relatively rare cases where we do want to pay attention to the semicolon boundaries, we want an explicit declaration that says not to flatten those semicolon boundaries. That's what I was aiming at with the Pipe declaration. : On Thu, Jun 16, 2005 at 08:53:41AM -0700, Larry Wall wrote: : The semicolon operator no longer builds a list of lists, but a list : of pipes, which are specially marked Lazies that know they came from : pipe operators (including semicolons as a kind of pipe operator). : When bound to an ordinary splat array (or in fact any splat array whose : type isn't Pipe), the Pipes flatten as if they were comma separated. : When bound to an array of type Pipe, each pipe stays discrete. : : I thought the class Pipe was reserved for what the result of open-foo| : is in Perl 5? That's what we call it in Prelude.pm at least; if it needs : to be renamed maybe IPC could work. I'm not stuck on using the word Pipe--it fact, if it's going to be an implicit mark, it should maybe be Huffman coded to something longer, MultidimensionalSliceComponent or some such... :-) On the other hand, system pipes could be called SysPipe, and it would be nice to think of these inner things as pipes, since that's what we're calling == and ==. But maybe declaring the type of the elements of the slurpy is the wrong approach anyway. Maybe it's the container type: sub zip ([EMAIL PROTECTED] is MultiDim) {...} or maybe even just a shape: sub zip ([EMAIL PROTECTED] is shape(*;Lazy) {...} What I'm trying to do here is to make the meaning of semicolon and pipes context-dependent, so that those contexts that want to care about the boundaries can care, and those contexts that don't want to care don't have to. On the flip side, I'd like to avoid inflicting another mandatory abstraction on the naive users, so I'm not really interesting in advertising a Pipe role for general use. Most new users won't realize that they're dealing with a dwimmy semicolon--they'll just cargo cult the notion that zip() takes a semicolon list. This does leave open the question of exactly which built-in list contexts do pay attention to pipe lists. Obviously, subscripts do. A list of values in parens doesn't. I think array and hash composers probably should pay attention, just because they look like subscripts. And because it's useful for readability to cut down the nesting of brackets by one level. However, they should probably warn if the only semicolon is at the end, on the assumption that it's accidental. On the other hand, we were using semicolon to differentiate hash composers from blocks, so that's a bit of an issue. Larry
Re: Ignoring parameters
On 6/16/05, Gaal Yahas [EMAIL PROTECTED] wrote: Say I have a class method in FooClass, callable as FooClass.greet(): method greet(Class $class: ) { say Hello, FooClass!; } Aside from the fact that I don't think this is the right way to specify class methods... AFAIK, this is the only signature that would work for making greet a class method; but note that I'm not using $class, and I'd expect the compiler to issue a warning in such a case. I don't think that the compiler should issue a warning in the case of unused parameters. Since the names of parameters mean something more than just how the method refers to them--they specify the names of named parameters--it could be useful to accept a parameter that is not used, in anticipation of them eventually being used. The unused parameter warning has never caught an error that undeclared variable hasn't for me (as long as I name things well), and usually is just a cue to bring out my UNUSED fingers. The same problem exists with methods in classes fulfilling a role, but which want to ignore a parameter in a required method. What do you say about this proposed syntax? method greet(Class undef: ) { ... } Or we could finally take an idea from C++, one that I don't think is so unreasonable: method greet(Class:) {...} Since there is no :: on the front of Class, it can't be mistaken for a parameter. That does bring up the question of what happens if you want to specify an indirect type as the type of a parameter. Maybe we just disallow that... Luke
scalar dereferencing.
my $x = 3; my $y = \$x; say $y + 10; $y++; say $y; say $x; Currently in Pugs they print: 13 4 3 Is this sane? What is the scalar reference's semantics in face of a stringification and numification? I assume that array/hash references simply pass on to the things they references to resolve stringify and numify, according to S02, but I had not been able to find mentioning about scalar refs Thanks, /Autrijus/ pgpqKSmU4ak2f.pgp Description: PGP signature
Re: Ignoring parameters
On Thu, Jun 16, 2005 at 01:26:31PM -0600, Luke Palmer wrote: Say I have a class method in FooClass, callable as FooClass.greet(): method greet(Class $class: ) { say Hello, FooClass!; } Aside from the fact that I don't think this is the right way to specify class methods... What do you think is the right way to specify them? -- Gaal Yahas [EMAIL PROTECTED] http://gaal.livejournal.com/
Re: sub my_zip (...?) {}
Larry Wall wrote: You must specify @foo[[;[EMAIL PROTECTED] or @foo[()] == @bar to get the special mark. I'm uncomfortable with the specific syntax of @a[()] because generated code might sometimes want to generate an empty list, and special-casing that sort of thing is always a pain (and fragile). An empty list of subscripts should return an empty slice. What this mark is really trying to say is The definition of the indices is coming from elsewhere. I'm wondering if these semtantics would make it appropriate to use the yada operator here: @foo[...] == @bar; Dave.
Re: Ignoring parameters
Gaal Yahas wrote: On Thu, Jun 16, 2005 at 01:26:31PM -0600, Luke Palmer wrote: Say I have a class method in FooClass, callable as FooClass.greet(): method greet(Class $class: ) { say Hello, FooClass!; } Aside from the fact that I don't think this is the right way to specify class methods... What do you think is the right way to specify them? I certainly can't speak for Luke, but I think the right way to specify class methods is: method greet(FooClass ::class:) { say Hello, FooClass!; } And I think that subs and methods *should* complain about all unused non-optional parameters *except* invocants. Damian
Re: sub my_zip (...?) {}
On Thu, Jun 16, 2005 at 01:05:22PM -0700, Dave Whipp wrote: : Larry Wall wrote: : You must : specify @foo[[;[EMAIL PROTECTED] or @foo[()] == @bar to get the special mark. : : I'm uncomfortable with the specific syntax of @a[()] because generated : code might sometimes want to generate an empty list, and special-casing : that sort of thing is always a pain (and fragile). An empty list of : subscripts should return an empty slice. If you don't actually pipe to it, a null list is exactly what it would be interpreted as, so I don't think it's a very big problem. And outside of generated code, () is always intentional. If there's a potential problem, it's with expecting @a == foo().bar() to feed bar() rather than foo(). So maybe that would have to be written @a == foo().bar(()) or @a == foo(()).bar() Or maybe as you say we just need a special term, though I don't think ... is it. : What this mark is really trying to say is The definition of the indices : is coming from elsewhere. I'm wondering if these semtantics would make : it appropriate to use the yada operator here: : :@foo[...] == @bar; That's cute, but I think that might be overloading the ... token a bit too much, and it's also rather likely to be confused with the postfix ... operator within subscripts. These would be too close, visually speaking: @foo[...] @foo[0...] I suppose a case could be made for @[EMAIL PROTECTED] or some such, since it's an inside out iterator. But () is prettier. Alternately we could go with the unix pipe character: @foo[|] Or maybe a splat @foo[*] Or go with the parens with something in them to indicate the positive absence of something. @foo[(*)] Anyone else want to have a go at this bikeshed? Larry
Re: Ignoring parameters
On 6/16/05, Damian Conway [EMAIL PROTECTED] wrote: And I think that subs and methods *should* complain about all unused non-optional parameters *except* invocants. This brings up something I've been thinking about. I sometimes write a method in Perl 5 that does something or other and then calls the superclass method of the same name, passing all arguments. Or sometimes I pull off an argument or two that only make sense to my method, leaving the rest for the superclass method. This is all easy when args are just items in the @_ array. Here are some Perl 5 examples: # Do something then proceed with call as usual sub foo { $_[0]-do_something_new(123, 'abc'); shift-SUPER::foo(@_); } # Pull off some args, do something, then proceed with call as usual sub foo { my($self, %args) = @_; $self-do_something_else(val = delete $args{'xyz'}); $self-SUPER::foo(%args); } Note that in both cases my foo() method doesn't know or care what SUPER::foo()'s arguments are. Now in Perl 6 I'll want to use fancy named parameters and so on, but I don't want to lose the abilities described above. How would those examples look in native Perl 6 code? (i.e., Without forcing all methods to have a single slurpy [EMAIL PROTECTED] argument, emulating the Perl 5 mechanisms.) -John
Re: Ignoring parameters
On Fri, Jun 17, 2005 at 07:05:11AM +1000, Damian Conway wrote: Gaal Yahas wrote: On Thu, Jun 16, 2005 at 01:26:31PM -0600, Luke Palmer wrote: Say I have a class method in FooClass, callable as FooClass.greet(): method greet(Class $class: ) { say Hello, FooClass!; } Aside from the fact that I don't think this is the right way to specify class methods... What do you think is the right way to specify them? I certainly can't speak for Luke, but I think the right way to specify class methods is: method greet(FooClass ::class:) { say Hello, FooClass!; } In the interest of keeping the design documents up-to-date, A12 says: To declare an ordinary class method, such as a constructor, you say something like: method new (Class $class: [EMAIL PROTECTED]) { ... } Such a method may only be called with an invocant that isa CClass, that is, an object of type CClass, or derived from type CClass. S12 says: Class methods are just methods that can take a class as their invocant. Somehow I read these as though the original poster was correct -- i.e., one creates a class method for FooClass as either method greet(Class $class:) { say Hello!; } or method greet(FooClass $class:) { say Hello!; } Are the design documents out of date in this regard? If so, can someone provide a patch, if not, can someone confirm that the design documents are correct? (I just happened to be looking at class methods this past week, which is why I was a little surprised by Luke and Damian's answers... :-) Pm
Re: Ignoring parameters
Patrick wrote: Somehow I read these as though the original poster was correct -- i.e., one creates a class method for FooClass as either method greet(Class $class:) { say Hello!; } Yes. That will work, but it's not the recommended solution. or method greet(FooClass $class:) { say Hello!; } No. That needs to be: method greet(FooClass ::class:) { say Hello!; } (as implied by takes a class as its invocant in S12). ^ Are the design documents out of date in this regard? If so, can someone provide a patch, if not, can someone confirm that the design documents are correct? (I just happened to be looking at class methods this past week, which is why I was a little surprised by Luke and Damian's answers... :-) Both documents are correct, but S12 is correcter (as you would expect). Damian
nested subs
So, I was about to write the following test for Pugs: sub factorial (Int $n) { my sub factn (Int $acc, $i) { return $acc if $i $n; factn( $acc * $i, $i+1); } factn(1, 1); } When I thought to check the apocalypses and exegeses and, what do you know, I couldn't find any evidence that nested named functions like this were legal. So, are they legal? And yes, I know there are other ways of doing this, but I like the lack of sigils on the function when you do it this way.
Re: nested subs
On 6/16/05, Piers Cawley [EMAIL PROTECTED] wrote: So, I was about to write the following test for Pugs: sub factorial (Int $n) { my sub factn (Int $acc, $i) { return $acc if $i $n; factn( $acc * $i, $i+1); } factn(1, 1); } When I thought to check the apocalypses and exegeses and, what do you know, I couldn't find any evidence that nested named functions like this were legal. So, are they legal? Yep. And they work just as if you had used an anonymous sub there--it closes over lexicals and everything. Luke
Re: nested subs
Luke Palmer [EMAIL PROTECTED] writes: On 6/16/05, Piers Cawley [EMAIL PROTECTED] wrote: So, I was about to write the following test for Pugs: sub factorial (Int $n) { my sub factn (Int $acc, $i) { return $acc if $i $n; factn( $acc * $i, $i+1); } factn(1, 1); } When I thought to check the apocalypses and exegeses and, what do you know, I couldn't find any evidence that nested named functions like this were legal. So, are they legal? Yep. And they work just as if you had used an anonymous sub there--it closes over lexicals and everything. I should bloody well hope so too.
Re: sub my_zip (...?) {}
On 6/16/05, Larry Wall [EMAIL PROTECTED] wrote: Or maybe a splat @foo[*] Or go with the parens with something in them to indicate the positive absence of something. @foo[(*)] Anyone else want to have a go at this bikeshed? You know, before I read this part of the message, I was thinking precisely that. Nullary splat should do it, so that @foo[*] will work. Unary splat would of course get our favor if it can be interpreted that way, but in cases like: @foo[*] bar(*) It is unambiguous, and you can always say (*) to disambiguate. I like the look of that too. Luke
When can I take given as read?
Suppose I have a simple, single argument recursive function: sub factorial (Int $n) { return 1 if $n == 0; return $n * factorial $n; } Can I write that as: sub factorial (Int $n:) { return 1 when 0; return $n * factorial $n; } NB. Yes, I know it's a pathological example.
Re: reduce metaoperator on an empty list
On Thursday 09 June 2005 12:21, John Macdonald wrote: On Thu, Jun 09, 2005 at 06:41:55PM +0200, TSa (Thomas Sandla wrote: Edward Cherlin wrote: That means that we have to straighten out the functions that can return either a Boolean or an item of the argument type. Comparison functions = = = != should return only Booleans, I'm not sure but Perl6 could do better or at least trickier ;) Let's assume that = = when chained return an accumulated boolean and the least or greatest value where the condition was true. E.g. 0 2 3 returns 0 but true 1 2 1 returns 1 but false 4 5 2 returns 2 but false Then the reduce versions [] and [=] naturally come out as min and strict min respectively. Is it correct that [min] won't parse unless min is declared as an infix op, which looks a bit strange? if 3 min 4 { ... } That's how it was done in APL. In fact, that's how every dyadic (two-argument) function was done in APL. It looks strange at first, but the syntax is simpler. I eat my peas with honey. I've done it all my life. It makes them taste real funny, But it keeps them on the knife. The natural method of implementation would imply that the final is returned: 0 2 3 returns 3 but true 1 2 1 returns 1 but false 4 5 2 returns 2 but false The application of each stage of the chain has to remember the right hand value (for the next stage of the comparison) as well as the accumulated boolean result. When the boolean result is true, that has and = returning the max, and and = returning the min - the opposite of what you asked above. In J one can do ()/ 0 1 1, evaluated as 0(11) 00 0 Then, since 00 is 0, and 01 is 1, 0 is a left identity of (restricted to Booleans), and /'' is defined to be 0. I don't suppose anybody here cares, but it turns out that Boolean scans have a variety of uses, such as running parity, locating transitions, and Gray Code to binary conversion, and Boolean identity elements have their uses within these schemes. -- Edward Cherlin Generalist activist--Linux, languages, literacy and more A knot! Oh, do let me help to undo it! --Alice in Wonderland http://cherlin.blogspot.com