In Perl 6, I don't think we need to tag methods as virtual like C++
does, since we have the handy yadda, yadda to do that for us.
However, there is a variant of C++'s virtual that I'd love to see. By
default a role cannot override the methods of a class, but if it could
override those methods
Hi,
now that the following works in Pugs :)...
sub infix:. (Code x, Code y) { sub ($z) { x(y($z)) } }
(say . int)(10/3);# 3
use Set;
sub infix: ($item, @set) {
set(@set).includes($item);
}
foo bar baz foo; # true
23 bar baz foo; # false
...we wondered
On 5/18/05, Aaron Sherman [EMAIL PROTECTED] wrote:
In Perl 6, I don't think we need to tag methods as virtual like C++
does, since we have the handy yadda, yadda to do that for us.
However, there is a variant of C++'s virtual that I'd love to see. By
default a role cannot override the
On 5/18/05, Ingo Blechschmidt [EMAIL PROTECTED] wrote:
(B Hi,
(B
(B now that the following works in Pugs :)...
(B
(B sub infix:. (Code x, Code y) { sub ($z) { x(y($z)) } }
(B (say . int)(10/3);# 3
(B
(B use Set;
(B sub infix:$B":(B ($item, @set) {
(B
On Wed, 2005-05-18 at 10:51, Luke Palmer wrote:
Except that mixins like this always treat things as virtual.
Whenever you mixin a role at runtime, Perl creates an empty, anonymous
subclass of the current class and mixes the role in that class. Since
roles beat superclasses, you'll always
HaloO Autrijus,
you wrote:
On Fri, May 13, 2005 at 07:13:53PM +0200, TSa (Thomas Sandlaß) wrote:
Larry Wall wrote:
: Void context still exists and is not a form of singular or plural
: context. Perhaps this should be called nullar context, although void
: context works equally well for me and is
Aaron Sherman wrote:
Ok, so log and log10:
multi sub Math::Basic::log (: Num ?$x = $CALLER::_, Num +$base);
log10 := log.assuming:base(10);
Sorry, I don't want to interfere but two nit-pickings from me:
1) It's log10:() and log:(: Num ?$, Num +$) these days, isn't it?
And I'm
HaloO Juerd,
you wrote:
(This illustrates my feeling about @foo[] being the same as @foo. It
feels inconsistent with foo() not being foo.)
I have the same feeling. But I would like @foo[] to mean something else
than plain @foo which should be---hmm, how shall I put that---a
underefenced reference
Juerd wrote:
my @b = [1,2,[3,4]];
is([EMAIL PROTECTED], 1, 'Array length, nested [], outer []s');
Isn't that a bit inconvenient? To get e.g. 2 out of @b
one has to write @b[0][1] while for $b a $b[1] suffices.
And @x = @b maintains this superficial level of indirection?
Does @x =
Autrijus Tang wrote:
I think the former is simpler (always use coercion), but the latter
makes it possible to define various other things that, although not
isomorphic with builtin numbers, can still use arithmetic operators.
I haven't understood what Larry meant with hard constraint but I would
On Wed, 2005-05-18 at 14:57, TSa (Thomas Sandlaß) wrote:
Aaron Sherman wrote:
Ok, so log and log10:
multi sub Math::Basic::log (: Num ?$x = $CALLER::_, Num +$base);
log10 := log.assuming:base(10);
Sorry, I don't want to interfere but two nit-pickings from me:
1)
Damian Conway wrote:
Now, personally, I would like to see a short-cut for *both* types of
method call,...
Looks like this syntax is now .method and ./method plus the private
counterpart .:method.
If I have .foo() as $_.foo(), then I can get unary method call on
invocant very easily, even if
Luke Palmer wrote:
And how do I explicitly define the precedence?
Using the `tighter`, `looser`, and `equiv` traits. You specify
precedence in terms of the precedence of other existing ops.
sub infix:.(f, g) is looser(infix:+) {...}
This is interesting. So, infix: is similar to Haskell's
()
Luke Palmer wrote:
In the absence of a trait specifying otherwise, the precedence
defaults to the same as infix:+.
Heh. It'd be much safer to *require* a precedence specification on any new
operator. If they're changing the parser, they ought to have the decency to be
explicit about precisely
TSa (Thomas Sandlaß) skribis 2005-05-18 21:54 (+0200):
Juerd wrote:
my @b = [1,2,[3,4]];
is([EMAIL PROTECTED], 1, 'Array length, nested [], outer []s');
Isn't that a bit inconvenient? To get e.g. 2 out of @b
one has to write @b[0][1] while for $b a $b[1] suffices.
All~
What does the reduce metaoperator do with an empty list?
my @a;
[+] @a; # 0? exception?
[*] @a; # 1? exception?
[] @a; # false?
[||] @a; # false?
[] @a; # true?
Also if it magically supplies some correct like the above, how does it
know what that value is?
Thanks,
Matt
--
Computer
Matt Fowles wrote:
All~
What does the reduce metaoperator do with an empty list?
my @a;
[+] @a; # 0? exception?
[*] @a; # 1? exception?
[] @a; # false?
[||] @a; # false?
[] @a; # true?
Also if it magically supplies some correct like the above, how does it
know what that value is?
My general
Matt Fowles wrote:
All~
What does the reduce metaoperator do with an empty list?
my @a;
[+] @a; # 0? exception?
[*] @a; # 1? exception?
[] @a; # false?
[||] @a; # false?
[] @a; # true?
Also if it magically supplies some correct like the above, how does it
know what that value is?
The usual
On 5/19/05, Matt Fowles [EMAIL PROTECTED] wrote:
All~
What does the reduce metaoperator do with an empty list?
/me puts on his lambda hat
In Haskell, there is a distinction between foldl and foldl1 (similar
remarks apply to foldr/foldr1[1]):
The former (foldl) requires you to give an
To summarise what I think everyone is saying, []-reducing an empty
list yields either:
1) undef (which may or may not contain an exception), or
2) some unit/identity value that is a trait of the operator,
depending on whether or not people think (2) is actually a good idea.
The usual
On 5/18/05, Stuart Cook [EMAIL PROTECTED] wrote:
To summarise what I think everyone is saying, []-reducing an empty
list yields either:
1) undef (which may or may not contain an exception), or
2) some unit/identity value that is a trait of the operator,
depending on whether or not people
Rob Kinyon wrote:
On 5/18/05, Stuart Cook [EMAIL PROTECTED] wrote:
To summarise what I think everyone is saying, []-reducing an empty
list yields either:
1) undef (which may or may not contain an exception), or
2) some unit/identity value that is a trait of the operator,
depending on whether or
Perl 6 Summary for 2005-05-03 through 2005-05-17
All~
Welcome ot another fortnight's summary. Wouldn't it just figure that I
can't think of anything sufficiently non-sequiterish to amuse myself.
Perhaps I need a running gag like Leon Brocard or chromatic's
cummingseque
Stuart Cook wrote:
To summarise what I think everyone is saying, []-reducing an empty
list yields either:
1) undef (which may or may not contain an exception), or
2) some unit/identity value that is a trait of the operator,
depending on whether or not people think (2) is actually a good idea.
The
Another alternative is to give the user the option of specifying such
a unit when using the reduction meta-operator, but this seems to work
against the whole point of [+] (which is brevity). If you want to
specify your own unit, use 'reduce'.
Can't the appropriate identity just be prepended?
25 matches
Mail list logo
