Re: A6: overloading multis on constness of parameters
In a message dated Thu, 13 Mar 2003, Luke Palmer writes:
{
my Class %valClasses;
sub Val($N) returns Class {
my Class $rclass = %valClasses{$N} //= class {
multi *isa ($obj, $rclass $class) { $obj ~~ $N }
}
}
}
multi factorial (Int Val(0) $g) { 1 }
Isn't this exactly what Cis cached is for?
sub Val($N) is cached returns Class {
class {
multi *isa ($obj, $rclass $class) { $obj ~~ $N }
}
}
multi factorial (Int Val(0) $g) { 1 }
(This is ignoring the fact that you can't use a runtime-evaluated sub in a
type declaration so the multi declaration wouldn't actually work.)
--
Trey Harris
Vice President
SAGE -- The System Administrators Guild (www.sage.org)
Opinions above are not necessarily those of SAGE.
Re: A6: overloading multis on constness of parameters
On Fri, Mar 14, 2003 at 01:45:56PM +1100, Damian Conway wrote: : Oh, and I was wrong to originally write: Cmulti *isa ... Sorry, you're not even wrong. :-) : Multimethods live in their own namespace. No * required. Alternately, we require the C* in order to accurately document their scope. And I do think they live in C*. Otherwise we need to come up with yet another name for the global scope that happens to contain multimethods. An argument can also be made that we should do that anyway on the grounds that we might someday have scoped multi-methods of some kind or other. I suppose can allow a Csub * in the same scope as Cmulti * for the case that you want a global override of all the multimethods. It just looks for the sub first. If that sub then wants to redispatch to the multimethods, it'd have to use some special multimethod syntax that doesn't look like a sub invocation, such as the notional ($a,$b,$c) forwhich foo() we talked about in Sebastopol, however we end up spelling forwhich. It's really a kind of postpositional topicalizer for the following predicate. English doesn't really have any good ones of those. If I were Japanese, I'd spell it wa or ga or no. Well, okay, I'd actually spell it or or if I were *really* Japanese. :-) Larry
Re: A6: overloading multis on constness of parameters
At 1:45 PM +1100 3/14/03, Damian Conway wrote:
Luke Palmer wrote:
Not that that couldn't be done with a closure anyway...
{
my Class %valClasses;
sub Val($N) returns Class {
my Class $rclass = %valClasses{$N} //= class {
multi *isa ($obj, $rclass $class) { $obj ~~ $N }
} }
}
multi factorial (Int Val(0) $g) { 1 }
I don't think so. I seriously doubt you can put a run-time-evaluated
sub call in a type specification visions of Dan fainting in horror
;-)
A Cmacro might do the trick though.
Hey, I'm perfectly happy to delegate the entirety of sub dispatch to
someone else's code. That's fine with me. ;-P
--
Dan
--it's like this---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
Re: A6: overloading multis on constness of parameters
Piers Cawley wrote:
Speaking of multis and constants, Greg McCarroll wondered on IRC if
this would work:
multi factorial (Int 0) { 1 }
multi factorial (Int $n) { $n * factorial($n-1) }
Probably not. We did discuss whether multimethods should be able to be
overloaded by value, but concluded (for that week, at least ;-) that this
might prove syntactically excessive.
Besides which, since multimethod dispatch will have to use Cisa to determine
type compatibility on parameters anyway, it's trivial to implement this form
of value-based dispatch yourself:
class Zero {
multi *isa ($obj, Zero $class) { $obj ~~ 0 }
}
# and then...
multi factorial (IntZero $g) { 1 }
or, supposing we have some form of parameterized types, you could create
something more generic like:
class Val($N) {
multi *isa ($obj, Val($N) $class) { $obj ~~ $N }
}
# and then...
multi factorial (IntVal(0) $g) { 1 }
;-)
Damian
Re: A6: overloading multis on constness of parameters
or, supposing we have some form of parameterized types, you could create
something more generic like:
class Val($N) {
multi *isa ($obj, Val($N) $class) { $obj ~~ $N }
}
# and then...
multi factorial (IntVal(0) $g) { 1 }
Yes, YES! Marvelous!
Not that that couldn't be done with a closure anyway...
{
my Class %valClasses;
sub Val($N) returns Class {
my Class $rclass = %valClasses{$N} //= class {
multi *isa ($obj, $rclass $class) { $obj ~~ $N }
}
}
}
multi factorial (Int Val(0) $g) { 1 }
Hmm, would Val(0) be evaluated at compile-time in that case... or must
I mark it with some sort of trait, or do some other kind of trick.
Cool, anyhow.
Luke
Re: A6: overloading multis on constness of parameters
Luke Palmer wrote:
Not that that couldn't be done with a closure anyway...
{
my Class %valClasses;
sub Val($N) returns Class {
my Class $rclass = %valClasses{$N} //= class {
multi *isa ($obj, $rclass $class) { $obj ~~ $N }
}
}
}
multi factorial (Int Val(0) $g) { 1 }
I don't think so. I seriously doubt you can put a run-time-evaluated sub call
in a type specification visions of Dan fainting in horror ;-)
A Cmacro might do the trick though.
Oh, and I was wrong to originally write: Cmulti *isa ...
Multimethods live in their own namespace. No * required.
Damian
Re: A6: overloading multis on constness of parameters
Joe Gottman [EMAIL PROTECTED] writes:
Will it be possible in perl6 to overload multis on the const-ness of a
parameter, like C++ does? For instance,
multi getX(Foo $self:) returns Int {...} #const version
multi getX(Foo $self: is rw) returns Int is rw {...} #non-const version
If getX were called on a const Foo object then the first getX would be
called, and if it were called on a non-const Foo object the second one would
be.
Speaking of multis and constants, Greg McCarroll wondered on IRC if
this would work:
multi factorial (Int 0) { 1 }
multi factorial (Int $n) { $n * factorial($n-1) }
Disregarding the fact that you should really write that as:
sub factorial (Int $n) {
my multi tail_fac ($result, 0) { $result }
my multi tail_fac ($result, $n) { tail_fac( $result * $n, $n - 1 ) }
tail_fac(1, $n);
}
(Assuming you want to do it recursively that is...)
--
Piers
Re: A6: overloading multis on constness of parameters
- Original Message -
From: Damian Conway [EMAIL PROTECTED]
To: Perl6 [EMAIL PROTECTED]
Sent: Tuesday, March 11, 2003 9:35 PM
Subject: Re: A6: overloading multis on constness of parameters
Joe Gottman wrote:
Will it be possible in perl6 to overload multis on the const-ness of
a
parameter, like C++ does? For instance,
multi getX(Foo $self:) returns Int {...} #const version
multi getX(Foo $self: is rw) returns Int is rw {...} #non-const
version
That second one would have to be:
multi getX(Foo $self is rw:) returns Int is rw {...}
Then we have the issue that Perl 6 objects can't really be constant,
since Cis constant is a compile-time trait of *containers*...really just
a don't assign to this container marker.
However, within those limitations, I guess it's possible. After all, we
have
to check for lvaluability of Cis rw parameters anyway.
How would I take a get a reference to the second one? I assume I could
get a reference to the first by
$ref = getX(Foo);
Joe Gottman
Re: A6: overloading multis on constness of parameters
On Wed, Mar 12, 2003 at 01:35:08PM +1100, Damian Conway wrote:
: Joe Gottman wrote:
:
:Will it be possible in perl6 to overload multis on the const-ness of a
: parameter, like C++ does? For instance,
:
:multi getX(Foo $self:) returns Int {...} #const version
:multi getX(Foo $self: is rw) returns Int is rw {...} #non-const version
:
: That second one would have to be:
:
: multi getX(Foo $self is rw:) returns Int is rw {...}
:
:
: Then we have the issue that Perl 6 objects can't really be constant,
: since Cis constant is a compile-time trait of *containers*...really just
: a don't assign to this container marker.
:
: However, within those limitations, I guess it's possible. After all, we
: have to check for lvaluability of Cis rw parameters anyway.
Might be one of those things that is taken as a tie-breaker, all other
things being equal. I'm thinking return types fall into the same category.
Larry
Re: A6: overloading multis on constness of parameters
- Original Message -
From: Damian Conway [EMAIL PROTECTED]
To: Perl6 [EMAIL PROTECTED]
Sent: Tuesday, March 11, 2003 9:35 PM
Subject: Re: A6: overloading multis on constness of parameters
Joe Gottman wrote:
Will it be possible in perl6 to overload multis on the const-ness of
a
parameter, like C++ does? For instance,
multi getX(Foo $self:) returns Int {...} #const version
multi getX(Foo $self: is rw) returns Int is rw {...} #non-const
version
That second one would have to be:
multi getX(Foo $self is rw:) returns Int is rw {...}
Then we have the issue that Perl 6 objects can't really be constant,
since Cis constant is a compile-time trait of *containers*...really just
a don't assign to this container marker.
However, within those limitations, I guess it's possible. After all, we
have
to check for lvaluability of Cis rw parameters anyway.
How would I take a get a reference to the second one? I assume I could
get a reference to the first by
$ref = getX(Foo);
Well, if there's overloading based on traits, siglets must support
traits. So, it would have to be:
$ref = getX(Foo is rw:);
(The first would be)
$ref = getX(Foo:);
Backwhacking those couldn't hurt, either.
Luke
A6: overloading multis on constness of parameters
Will it be possible in perl6 to overload multis on the const-ness of a
parameter, like C++ does? For instance,
multi getX(Foo $self:) returns Int {...} #const version
multi getX(Foo $self: is rw) returns Int is rw {...} #non-const version
If getX were called on a const Foo object then the first getX would be
called, and if it were called on a non-const Foo object the second one would
be.
Joe Gottman
Re: A6: overloading multis on constness of parameters
Joe Gottman wrote:
Will it be possible in perl6 to overload multis on the const-ness of a
parameter, like C++ does? For instance,
multi getX(Foo $self:) returns Int {...} #const version
multi getX(Foo $self: is rw) returns Int is rw {...} #non-const version
That second one would have to be:
multi getX(Foo $self is rw:) returns Int is rw {...}
Then we have the issue that Perl 6 objects can't really be constant,
since Cis constant is a compile-time trait of *containers*...really just
a don't assign to this container marker.
However, within those limitations, I guess it's possible. After all, we have
to check for lvaluability of Cis rw parameters anyway.
Damian
