Re: Object Order of Precedence (Was: Vocabulary)
Larry Wall wrote:
> Jonathan Lang wrote:
> : Larry Wall wrote:
> : > Jonathan Lang wrote:
> Also, there will be access to the list of call candidates for SUPER::
> (and presumably ROLE::) such that the class's method can get explicit
> control of which super/role method or methods get called. So we can
> have methods that fail-over to the next candidate. It's just not the
> default way to resolve multiple methods with the same signature.
Make micromanaging possible, but not mandatory. Sounds good to me.
> : > Another possibility is that the class's method could be declared to
> : > be the default multi method in case the type information is not
> : > sufficient to decide which role's multi method should be called.
> : > Maybe if it's declared "multi" it works that way. Otherwise it's
> : > just called first automatically.
> :
> : ...meaning that the question of "which role do you mean?" has already
> : been addressed by the time the ROLE:: "deference" gets used.
>
> No, in this case the ROLE:: deference has already given up on finding
> a unique role to call, and called the class's method to break the tie,
> or do something really generic, or call more than one of the role
> methods, or die.
Oh; OK.
> : Although I'm not following what you're saying here in terms of the
> : third means of disambiguation. Could someone provide an example,
> : please?
>
> role Pet {
> method feed (PetFood $x) {...}
> }
> role Predator {
> method feed (PredatorFood $x) {...}
> }
> class DangerousPet does Pet does Predator {
> }
>
> If DangerousPet doesn't define a feed method at all, then we might
> dispatch to Pet and Predator as if their methods had an implicit
> "multi".
And the C trait is the tie-breaker when several options are
equally likely candidates (in terms of type information); OK.
So what happens if more than one of the candidates is tagged as the
default? The same thing as if none of them was? This could happen if
both Predator and Pet have declared their 'feed' methods as the default.
> Arguably, the role's might be required to declare their methods "multi"
> if they want to participate in this, but that's one of those things
> that feel like they ought to be declared by the user rather than the
> definer. On the other hand, maybe a role would feel that its method
> *must* be unique, and leaving out the "multi" is the way to do that.
> But I hate to get into the trap of culturally requiring every method
> in every role to specify "multi". It's a little too much like the C++
> ubiquitous-const problem.
What about making multi dispatches the assumed behavior, with a C
keyword to explicitly shut it off (for the sake of optimization)? That
is, replace the C keyword used to define routines that participate
in multiple dispatching with a C keyword used to define routines
that don't.
> My hope for unifying traits and superclasses is that, if you call an
> ordinary class using "is", the wicked thing that it does is insert
> itself into the "ISA" property of the class.
When you say "is foo", you're inheriting if foo is a class and you're
adding a trait if foo is a trait. OK. This would also imply that the
proper way to access a trait's namespace would be identical to the
explicit means of accessing a superclass's namespace.
> Where that may cause problems if you want to inherit from an existing
> trait that does something else wicked. But then, traits aren't often
> going to be inherited anyway, since their purpose is to break the
> rules.
Unless you're trying to create a variation on an existing trait, of
course.
> We can maybe inherit from classof(trait) to get around any difficulties.
Perhaps you could use C instead of C? More concise and
just as meaningful.
> So I'm still thinking we do inheritance with "is" rather than "isa".
> We just have to keep our names straight. Generally, traits will
> be lowercase, and true class or role names start with an uppercase
> letter.
But then, this remains merely a convention; a sloppy programmer (or one
who isn't worried about his code being extensible) could violate it
without the compiler complaining.
The only fear that I have here is whether we're violating the "different
things should look different" principle: are traits and superclasses
similar enough to each other to be added to a class by the same means? It
might not be a bad idea to include "isa" as a more explicit alternative to
"is", with the added benefit that "isa traitname" would be short for "is
classof(traitname)". It also occurs to me that traits can be thought of
as adjectives (thus the "is " vs. "is a " distinction) -
another way to attach an adjective to a noun in English is to prepend it
to the noun:
my Dog $Spot is red;
my black Cat $Tom;
my thoughtful $Larry is overworked;
where red, black, thoughtful, and overworked are traits.
Or is this too much?
In a similar vein, what a
Re: This week's summary
* The Perl 6 Summarizer <[EMAIL PROTECTED]> [2003-12-16 11:57]: > bear in mind that the authors of the paper use the term > 'trait' for what we're calling a 'role' (We already have > traits you see). > > http://www.cse.ogi.edu/~black/publications/TR_CSE_02-012.pdf > -- Traits paper I think it deserved mention that at least Larry has taken to capitalizing "Trait" when referring to the paper's idea of Traits that we call roles, and leaving "trait" lowercased when referring to traits of the Perl 6 fashion. -- Regards, Aristotle "If you can't laugh at yourself, you don't take life seriously enough."
Re: but true
Larry Wall wrote:
> Maybe there's an intermediate syntactic form like:
>
> $x but subclass MyClass does FooBar[bar] { }
IMHO, C should be defined as generating a singleton class that
derives from the variable's class and composes a specified role - but not
neccessarily a I role. How about defining it such that the
presence of C, C, or curly braces immediately following C
implies that the term is an anonymous role definition:
$x but is red does bar { }
eqv
role AnonRole is red does bar { }
$x but AnonRole;
eqv
role AnonRole is red does FooBar[bar] { }
$x but AnonRole;
You never slatheron more than one role at a time; but you can create the
role that you're going to slatheron on the fly. Potential problem:
identifying duplicate anonymous roles (an issue of optimization). The
upside: once that problem's solved, the problem of caching singleton
classes is greatly simplified. Also, it removes the run-time $x from the
compile-time side of things.
There's one "degenerate case" for on-the-fly roles:
$x but does foo { }
eqv
$x but foo;
=
Jonathan "Dataweaver" Lang
__
Do you Yahoo!?
New Yahoo! Photos - easier uploading and sharing.
http://photos.yahoo.com/
Re: Object Order of Precedence (Was: Vocabulary)
On Sat, Dec 20, 2003 at 12:41:10PM -0800, Jonathan Lang wrote:
: So what happens if more than one of the candidates is tagged as the
: default? The same thing as if none of them was? This could happen if
: both Predator and Pet have declared their 'feed' methods as the default.
Could blow up, or look for a more generic default that isn't in a tie.
The latter seems more fail-soft, since something else of the same name
is likelier to know what to do than some random exception handler in
who-knows-what dynamic context.
: > Arguably, the role's might be required to declare their methods "multi"
: > if they want to participate in this, but that's one of those things
: > that feel like they ought to be declared by the user rather than the
: > definer. On the other hand, maybe a role would feel that its method
: > *must* be unique, and leaving out the "multi" is the way to do that.
: > But I hate to get into the trap of culturally requiring every method
: > in every role to specify "multi". It's a little too much like the C++
: > ubiquitous-const problem.
:
: What about making multi dispatches the assumed behavior, with a C
: keyword to explicitly shut it off (for the sake of optimization)? That
: is, replace the C keyword used to define routines that participate
: in multiple dispatching with a C keyword used to define routines
: that don't.
Now that's...an *interesting* idea. Maybe even worth some punctuation
right there in the name. Maybe "is unique" is written:
my sub print! ([EMAIL PROTECTED]) {...}
meaning: "Always call this one, dang it!"
Then maybe "is default" could be
my sub print? ([EMAIL PROTECTED]) {...}
meaning: "Call this one in case of a tie?"
The character would only be in the declaration, not in the call.
(Of course, that prevents us from actually using those characters in
names like Ruby does, but I'm not sure that's a big loss.)
But I'm getting sidetracked. The underlying question is whether "multi"
should be the default. And that's still an interesting idea regardless
of the syntax.
Another unexplored question is how and whether to open up multiple
dispatch to more scopes than just the first one in which you find
the name, which is the normal Perl6 semantics. I doubt looking
everywhere should be the default, but just as a class might call any
or all of its roles' methods, a lexically scoped sub might want to
call or dispatch to any set of subs of that name that are visible in
the current scope. Naming such collections is an interesting problem.
Taking scope transitions into account in the distance calculation of
multi signatures could be even more interesting. If you define your
own multi foo, and there's a global multi foo, how far away is that?
Is it worth a level of inheritance in one of the arguments? Is it
worth more? Less? Is it worth anything, if you've included both
in your set of possible multis to begin with?
[Should probably change the Subject if you want reply to this one.
In fact, I should probably have split this message into separate
responses...]
: > Where that may cause problems if you want to inherit from an existing
: > trait that does something else wicked. But then, traits aren't often
: > going to be inherited anyway, since their purpose is to break the
: > rules.
:
: Unless you're trying to create a variation on an existing trait, of
: course.
Which might well be done with wrappers rather than via inheritance. I
don't think traits are going to have a lot of methods you'd want to
inherit.
On the other hand, applying a container type to a container is currently
done with C, and one might very well want to inherit from a container
type, which (like Perl 5 tie classes) might have oodles of inheritable
methods. But then, C isn't ambiguous because you're not using it
on a class at that point, so maybe it's still okay...
: > We can maybe inherit from classof(trait) to get around any difficulties.
:
: Perhaps you could use C instead of C? More concise and
: just as meaningful.
Unless C encompasses roles and subtypes but C doesn't...
Still, if you're using C on a "real" object, it has to be a class.
Probably ought to be C if we want to reserve C for a
declarator keyword. Though if we end up with typed refs, we could
well end up with a situation where classof($self) returns DangerousPet
but typeof($self) returns Predator.
: > So I'm still thinking we do inheritance with "is" rather than "isa".
: > We just have to keep our names straight. Generally, traits will
: > be lowercase, and true class or role names start with an uppercase
: > letter.
:
: But then, this remains merely a convention; a sloppy programmer (or one
: who isn't worried about his code being extensible) could violate it
: without the compiler complaining.
Certainly.
: The only fear that I have here is whether we're violating the "different
: things should look different" principle: are traits and superclasses
: similar enough to each other to be a
Re: but true
[EMAIL PROTECTED] (Larry Wall) writes:
> is classof($x)
Ouch. $x's class isn't a property or trait of it?
> class AnonClass is classof($x) does FooBar { }.bless($x, foobar => bar)
I don't understand what the bit at the end is doing. This is calling .bless
on the overriden method? And I'm not sure I follow the 'foobar => bar'.
> I think I'm happier with that. $rubyometer += 0.3 or so. :-)
Except it loses about 5 points for that classof thing. ;)
--
As in certain cults it is possible to kill a process if you know its true name.
-- Ken Thompson and Dennis M. Ritchie
dispatching (was: Object Order of Precedence)
Larry Wall wrote:
> Jonathan Lang wrote:
> : > Arguably, the role's might be required to declare their methods
> : > "multi" if they want to participate in this, but that's one of those
> : > things that feel like they ought to be declared by the user rather
> : > than the definer. On the other hand, maybe a role would feel that
> : > its method *must* be unique, and leaving out the "multi" is the way
> : > to do that. But I hate to get into the trap of culturally requiring
> : > every method in every role to specify "multi". It's a little too
> : > much like the C++ ubiquitous-const problem.
> :
> : What about making multi dispatches the assumed behavior, with a
> : C keyword to explicitly shut it off (for the sake of
> : optimization)? That is, replace the C keyword used to define
> : routines that participate in multiple dispatching with a C
> : keyword used to define routines that don't.
>
> Now that's...an *interesting* idea. Maybe even worth some punctuation
> right there in the name. Maybe "is unique" is written:
>
> my sub print! ([EMAIL PROTECTED]) {...}
>
> meaning: "Always call this one, dang it!"
>
> Then maybe "is default" could be
>
> my sub print? ([EMAIL PROTECTED]) {...}
>
> meaning: "Call this one in case of a tie?"
>
> The character would only be in the declaration, not in the call.
Perhaps; but I'd want the more verbose approach available as well.
> (Of course, that prevents us from actually using those characters in
> names like Ruby does, but I'm not sure that's a big loss.)
>
> But I'm getting sidetracked. The underlying question is whether "multi"
> should be the default. And that's still an interesting idea regardless
> of the syntax.
>
> Another unexplored question is how and whether to open up multiple
> dispatch to more scopes than just the first one in which you find
> the name, which is the normal Perl6 semantics. I doubt looking
> everywhere should be the default, but just as a class might call any
> or all of its roles' methods, a lexically scoped sub might want to
> call or dispatch to any set of subs of that name that are visible in
> the current scope. Naming such collections is an interesting problem.
Naming in what way? As a descriptive term for discussing them in general,
or naming individual collections for reference purposes in the code?
> Taking scope transitions into account in the distance calculation of
> multi signatures could be even more interesting. If you define your
> own multi foo, and there's a global multi foo, how far away is that?
> Is it worth a level of inheritance in one of the arguments? Is it
> worth more? Less? Is it worth anything, if you've included both
> in your set of possible multis to begin with?
Why not do it the same way that namespace scoping collisions are resolved:
the local scope trumps the caller's scope. Rinse, lather, repeat.
=
Jonathan "Dataweaver" Lang
__
Do you Yahoo!?
New Yahoo! Photos - easier uploading and sharing.
http://photos.yahoo.com/
Re: dispatching (was: Object Order of Precedence)
On Sat, Dec 20, 2003 at 03:12:53PM -0800, Jonathan Lang wrote: : Naming in what way? As a descriptive term for discussing them in general, : or naming individual collections for reference purposes in the code? I meant naming primarily as in how you select a particular group of them. They don't have to have an official name, as long as you can get a ref to the list of candidates. : > Taking scope transitions into account in the distance calculation of : > multi signatures could be even more interesting. If you define your : > own multi foo, and there's a global multi foo, how far away is that? : > Is it worth a level of inheritance in one of the arguments? Is it : > worth more? Less? Is it worth anything, if you've included both : > in your set of possible multis to begin with? : : Why not do it the same way that namespace scoping collisions are resolved: : the local scope trumps the caller's scope. Rinse, lather, repeat. That's the default behavior--you ignore multi until you find the name in a particular namespace, then you look to see if there are multis within that namespace. I'm talking about what if you don't like the default behavior where the collection is limited to the one namespace. Or to look at it another way, by default, the distance between namespaces is infinitely large compared to the distance between multimethods in a namespace. That might not always be what people want. In particular, sometimes people might want the namespace distance to be 0, and consider equally all multis of that name in any (visible) namespace. It's a valid thing to want, but I just don't think it should be the default. Larry
trait declarations (was: Object Order of Precedence)
Larry Wall wrote: > Jonathan Lang wrote: > : It also occurs to me that traits can be thought of > : as adjectives (thus the "is " vs. "is a " distinction) - > : another way to attach an adjective to a noun in English is to prepend > : it to the noun: > : > : my Dog $Spot is red; > : my black Cat $Tom; > : my thoughtful $Larry is overworked; > : > : where red, black, thoughtful, and overworked are traits. > : > : Or is this too much? > > It's not too much for English. :-) > > But it is a little confusing in Perl because people might think > $Larry returns things of type "thoughtful", rather than thoughtful > being applied to the container type. Then again, this is the exact same sort of confusion that could occur with C: sometimes it adds a trait, and other times it results in single or multiple inheritence. If people can be trusted to keep them straight there, I don't see why the prepended version would be any more difficult. > And > > my black Cat $Tom; > > would be taken to mean something like: > > my $Tom returns (Cat is black); > > rather than > > my $Tom is black returns Cat; > > Maybe that's okay, but we haven't really talked about applying traits > to classes outside of declarations, and what that would denote. A somewhat more serious example: my const Num $pi = 3.141592653589793238462643383279502884197169399; would be equivelent to my $pi is const returns Num = 3.141592653589793238462643383279502884197169399; unless you want to define an anonymous class representing a constant number. = Jonathan "Dataweaver" Lang __ Do you Yahoo!? New Yahoo! Photos - easier uploading and sharing. http://photos.yahoo.com/
junctive classes (was: Object Order of Precedence)
Larry Wall wrote:
> Jonathan Lang wrote:
> : In a similar vein, what about making a disjunction of classes in an
> : C or C clause synonymous with a sequence of appropriate
> : clauses? Ditto with traits and C, roles and C, attributes
> : and C, etc.; thus:
> :
> : class DangerousPet does Pet & Predator {
> : }
> :
> : would be the same as
> :
> : class DangerousPet does Pet does Predator {
> : }
>
> Depends on how you look at it. A DangerousPet is something that can
> act like either a Pet or a Predator, or both. Sometimes you want &
> and sometimes you want |. (Of course, a lawyer will tell you that
> "and" and "or" mean the same thing in a legal document.) I suppose
> there could even be some sense in
>
> class DangerousPet does Pet ^ Predator {
> }
>
> meaning it can be a Pet or a Predator but not both at the same time.
> Of course, that probably means that you can't actually have any
> objects of type DangerousPet. Or maybe it does, but you can't call
> any ambiguous DangerousPet methods without casting to either Pet or
> Predator. Hmm...
Since disjunctions are unambiguous in their membership, this isn't a
problem for them; only for disjunctions, ajunctions, and (horrors!)
injunctions. Admittedly, a class that C an ajunction of classes would
be a cute way of creating something conceptually akin to a C union.
I could see practical uses for the disjunctive forms; even there, I'm not
sure that the coding required to make the compiler handle things would be
worth the time invested - but it just might be. I'm even less sure when
it comes to the other kinds of junctions.
> That would mean that C implies a constraint test on typeof($self)
> rather than classof($self). (Presuming typed refs in the first place,
> of course.)
OTOH, C, C, and C are declarative in nature, not
predicative; it's much like assignment vs. equality.
=
Jonathan "Dataweaver" Lang
__
Do you Yahoo!?
New Yahoo! Photos - easier uploading and sharing.
http://photos.yahoo.com/
Re: dispatching (was: Object Order of Precedence)
On Sat, Dec 20, 2003 at 03:21:10PM -0800, Larry Wall wrote:
: On Sat, Dec 20, 2003 at 03:12:53PM -0800, Jonathan Lang wrote:
: : Why not do it the same way that namespace scoping collisions are resolved:
: : the local scope trumps the caller's scope. Rinse, lather, repeat.
Actually, I didn't see that you said "caller's scope". That would imply
some kind of dynamic scoping to multis, which I doubt we'll support
except insofar as you can temporize a global name.
: That's the default behavior--you ignore multi until you find the name
: in a particular namespace, then you look to see if there are multis
: within that namespace. I'm talking about what if you don't like the
: default behavior where the collection is limited to the one namespace.
:
: Or to look at it another way, by default, the distance between
: namespaces is infinitely large compared to the distance between
: multimethods in a namespace. That might not always be what people
: want. In particular, sometimes people might want the namespace
: distance to be 0, and consider equally all multis of that name in any
: (visible) namespace. It's a valid thing to want, but I just don't
: think it should be the default.
I should say, however, that the current lexical scope, the current
package scope, and the *name global scope are all considered to be
potentially the "current" namespace in just the same way as for a
variable name. That is, any lexical declarations hide corresponding
package or global declarations, and any package declarations hide
corresponding global declarations. The question is what we mean by
"corresponding". It may well be that for multis the definition of
"corresponding" includes the signature, so that you could mix generic
global multis with more specific package or lexical multis.
The question I was trying to address was whether outer lexical multis
should be hidden if there are any inner lexical mutlis of the same name,
regardless of signature. Hmm. Now that I put it that way, it sounds
as though the default should be to hide only the outer multis with
the same signature, on the simple theory that a subroutine's complete
name always includes its signature. You could always hide the outer
ones with "is unique" (or however we do it). The fact that you might
want to do this frequently is an argument for a shorthand such as
my sub name!
If we do it that way, people will want to have a way to say that the
inner lexical scope supplies all of the multis of that name. Perhaps
one can declare the name separately from the individual subs, as long
as one didn't supply a signature:
my sub name is unique {...};
my sub name (Foo $x) {...}
my sub name (Bar $x) {...}
my sub name ($x) is default {...}
or
my sub name! {...};
my sub name (Foo $x) {...}
my sub name (Bar $x) {...}
my sub name? ($x) {...}
Hmm.
Larry
Re: [perl] Re: Object Order of Precedence (Was: Vocabulary)
- Original Message - From: "Jonathan Lang" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Saturday, December 20, 2003 3:41 PM Subject: [perl] Re: Object Order of Precedence (Was: Vocabulary) > Larry Wall wrote: > > If DangerousPet doesn't define a feed method at all, then we might > > dispatch to Pet and Predator as if their methods had an implicit > > "multi". > > And the C trait is the tie-breaker when several options are > equally likely candidates (in terms of type information); OK. I'm a little leery about calling this trait "default". The problem is that we are already using "default" as a keyword (see the switch statement), and having a trait with the same name as a keyword might confuse users and/or the compiler. Joe Gottman
Re: [perl] Re: Object Order of Precedence (Was: Vocabulary)
Joe Gottman writes: > > - Original Message - > From: "Jonathan Lang" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Saturday, December 20, 2003 3:41 PM > Subject: [perl] Re: Object Order of Precedence (Was: Vocabulary) > > > > Larry Wall wrote: > > > If DangerousPet doesn't define a feed method at all, then we might > > > dispatch to Pet and Predator as if their methods had an implicit > > > "multi". > > > > And the C trait is the tie-breaker when several options are > > equally likely candidates (in terms of type information); OK. > >I'm a little leery about calling this trait "default". The problem is > that we are already using "default" as a keyword (see the switch statement), > and having a trait with the same name as a keyword might confuse users > and/or the compiler. Perl's using a top-down compiler now, so it won't be looking for the keyword variant of C after "is". "default" is sufficiently overloaded in English, and by context in Perl, that I don't think anyone will get confused. Not to say that other names for this trait aren't welcome. Luke
Re: [perl] Re: Object Order of Precedence (Was: Vocabulary)
Luke Palmer wrote: Joe Gottman writes: - Original Message - From: "Jonathan Lang" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Saturday, December 20, 2003 3:41 PM Subject: [perl] Re: Object Order of Precedence (Was: Vocabulary) Larry Wall wrote: If DangerousPet doesn't define a feed method at all, then we might dispatch to Pet and Predator as if their methods had an implicit "multi". And the C trait is the tie-breaker when several options are equally likely candidates (in terms of type information); OK. I'm a little leery about calling this trait "default". The problem is that we are already using "default" as a keyword (see the switch statement), and having a trait with the same name as a keyword might confuse users and/or the compiler. Perl's using a top-down compiler now, so it won't be looking for the keyword variant of C after "is". "default" is sufficiently overloaded in English, and by context in Perl, that I don't think anyone will get confused. Not to say that other names for this trait aren't welcome. C
