RE: A modest question (Damian, see last para please?)
Jonathan Lang [mailto:[EMAIL PROTECTED] wrote:
> Austin Hastings wrote:
> > Indeed. I like the idea of dynamic anonymous roles -- it's more
> > behavioral than anything else.
> >
> > sub print_it ($thingie must stringify()) {...}
> >
> > Definitely gets down to the lowest level quickly, which is nice. Even
> > nicer is the ability to use this sort of requirement as kind of an
> > advanced signature: declare exactly what you're going to do. (In other
> > words, your signature may say
> >
> > sub foo(Object $o) {...}
> >
> > because you want to accept anything in the hierarchy. But it's nice to
> > extend it with
> >
> > sub foo(Object $o must stringify() must isa() must typeof()) {...}
>
> Valid, if wordy. Roles remain useful in that they provide a more concise
> way of handling this if you want it - if you've got a dozen routines that
> all C, you might be better off defining a role
> that makes those demands, and then just use it.
Sure, I agree. But when you want to specify exactly what you're doing (sort
of like call-by-contract, I guess) you can get really detailed. When you
have a dozen common cases, define an inferred role. But if any object with
methods A, Q, and Z are going to be acceptable, why not?
> > This kind of granularity does kind of imply a JavaScript-like ability to
> > compose objects, too, no? (If you can compose requirements atomically,
> > why not compose capabilities, too?)
> >
> > my $photon does Particle does Wave {...} = spark();
>
> That's where C comes in:
>
>my $photon but does Particle does Wave {...} = spark();
>
> would be equivelent to something like
>
>class _anonymous_photon does Particle does Wave {...}
>my _anonymous_photon $photon = spark();
Is that ['but'] really necessary?
> > > Also: in the first of these two, would classof($thingie) actually have
> > > to have Stringify as a role, or would it be reasonable to instead say
> > > that classof($thingie) must meet Stringify's demands? The latter
> > > would require more work on the compiler's part, but would be
> > > considerably more flexible.
> >
> > I prefer the latter. I want to be able to compose requirements on the
> > way. I certainly don't want to have to rewrite the core libraries (or
> > extend them all) just to mix in an interface role that they already
> > satisfy.
>
> In principle, I agree with you; in practice, it may not be workable.
Verification should be just as easy for this as for a typed referenced
parameter. I don't see why it wouldn't be workable.
> > > Perhaps "Stringify $thingie" requires that the Stringify role must
> > > actually be used, while something like "$thingie like Stringify" would
> > > only require that Stringify's demands be met?
> >
> > My thought would be that once you have an object in hand, you can do
> > with it what you will. But all you get is the object.
>
> How would you handle the following:
>
>role Dog {must bark();}
>role Tree {must bark();}
>
>class crossPerson {
> method bark() {speak_sharply;}
>}
>
>class Trog does Tree does Dog {
> method bark() {bark_like_a_trog;}
>}
>
>multi sub purchase(Dog $mansBestFriend) {...}
>multi sub purchase(Tree $shrubbery) {...}
>multi sub purchase($noisemaker must bark()) {...}
>
>my crossPerson $jack;
>purchase $jack;
>
>my Trog $spot;
>purchase $spot;
>
> Which, if any, of the subs should be called in each case? Or should the
> compiler complain of duplicate definitions?
$jack is a crossPerson, which absolutely does NOT have the Dog or Trog or
Tree classes in its C chain. If Dog and Tree are both "inferred" or
"inferrable" classes, then the two multi declarations (Dog and Tree
arguments) are identical.
Thus, there's probably a warning or an error about conflict of inference for
any call that's not passed an explicitly typed object.
Given the strictness of the C behavior, I think that the consistent
answer is to fail as soon as possible and report that the three purchase
subs are in conflict with each other.
(In the generally interesting case of what to do with the Dog/Tree
multisubs, I think the right answer is to catch this either when class Trog
is declared, or when C is called. Comments from @Larry,
especially Damian, would be nice.)
=Austin
RE: A modest question
From: chromatic [mailto:[EMAIL PROTECTED]
> On Wed, 2004-01-07 at 00:43, Jonathan Lang wrote:
> > Maybe as an alternative to
> >
> >role Stringify {must stringify();}
> >sub print_it (Stringify $thingie) {print $thingie.stringify();}
> >
> > you might be able to say
> >
> >sub print_it ($thingie must stringify()) {print
> $thingie.stringify();}
> >
> > Hmm... there's a certain elegance to being able to specify one or two
> > requirements directly in a signature.
>
> I'm not sure that works so well in practice. You're explicitly asking
> for a method with a particular name when you're ought to be asking for a
> method with a particular meaning. That is, if you said:
>
> method threaten ( $thingie must bark() ) { ... }
>
> passing in a Tree object would work, when what you really want something
> that does Doggish things, like a Dog, an Actor in a dog costume, or a
> RobotDog.
Ahh, this is the classic Damian interpretation.
Yes, passing in a Tree would satisfy the requirement. That's the intention.
If we wanted to say that the requirement was for a Dog role, we'd say that.
Instead, we're being very generic, and saying that anything with a bark()
method is valid fodder for this.
For example,
sub bark_louder($it must bark()) {
System::Audio::set_volume(+5);
$it.bark;
System::Audio::set_volume(-5);
}
> Promoting role names to a position of typishness allows roles to express
> the semantics and context of method names that method names alone can't
> express uniquely.
>
> Yikes, now I sound like Larry.
Sure, but you're missing the point. It's not "methods instead of roles",
it's "methods when even roles are too abstract."
=Austin
Archive tarball?
Is there somewhere I can get the entire perl6-language archive in a tarball? I am trying to work on turning the Apocalypses into story cards at http://p6stories.kwiki.org. It would be helpful to me if I could search the mailing list archives to make sure I incorporate any decisions made after each Apocalypse was written. As there is no search engine at this moment ( that is not a whine or a complaint, merely a statement ), the next best thing for me would be a tarball I could grep. TIA, Mik --- Mik Firestone
Re: Archive tarball?
[EMAIL PROTECTED] (Michael.Firestone) writes: > As there is no search engine at this moment groups.google.com might work for you. -- Wouldn't you love to fill out that report? "Company asset #423423 was lost while fighting the forces of evil." -- Chris Adams in the scary.devil.monastery
Re: Archive tarball?
michael.firestone writes: > Is there somewhere I can get the entire perl6-language archive in a > tarball? I personally don't know, but there could be somewhere. > I am trying to work on turning the Apocalypses into story cards at > http://p6stories.kwiki.org. It would be helpful to me if I could search > the mailing list archives to make sure I incorporate any decisions made > after each Apocalypse was written. As there is no search engine at this > moment ( that is not a whine or a complaint, merely a statement ), the next > best thing for me would be a tarball I could grep. Well, most of the decisions you'll find in the "official" documents: the apocalypses, exegeses, and synopses. perl6-language has a lot of brainstorming, and a lot of Larry saying something interesting in the form of "maybe ...", but those could hardly be considered decisions. If worse comes to worst, you can always ask me. I manage to keep the largest amount of the language in my head with the most time available to answer questions :-) Oh, and thanks for the p6stories work. Luke
Re: Archive tarball?
On Thu, Jan 08, 2004 at 07:48:46AM -0700, Luke Palmer wrote: > Well, most of the decisions you'll find in the "official" documents: the > apocalypses, exegeses, and synopses. Yeah, but those are lagging behind in syntax changes (for instance). It helps to use the right vocabulary when coming up with the stories :-) > If worse comes to worst, you can always ask me. I manage to keep the > largest amount of the language in my head with the most time available > to answer questions :-) Oh no, now *everybody* will be asking you stuff. :-) -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: Archive tarball?
At 09:25 AM 1/8/2004 -0600, Jonathan Scott Duff wrote: On Thu, Jan 08, 2004 at 07:48:46AM -0700, Luke Palmer wrote: > If worse comes to worst, you can always ask me. I manage to keep the > largest amount of the language in my head with the most time available > to answer questions :-) Oh no, now *everybody* will be asking you stuff. :-) Are we taking periodic backups of Luke? =) -Melvin
RE: A modest question
Austin Hastings wrote:
> Jonathan Lang wrote:
> > Austin Hastings wrote:
> > > This kind of granularity does kind of imply a JavaScript-like
> > > ability to compose objects, too, no? (If you can compose
> > > requirements atomically, why not compose capabilities, too?)
> > >
> > > my $photon does Particle does Wave {...} = spark();
> >
> > That's where C comes in:
> >
> >my $photon but does Particle does Wave {...} = spark();
> >
> > would be equivelent to something like
> >
> >class _anonymous_photon does Particle does Wave {...}
> >my _anonymous_photon $photon = spark();
>
> Is that ['but'] really necessary?
Maybe; maybe not. How about this:
When you apply C directly to an object, the result is that the
object's class is changed to a singleton class identical to its previous
class except that it also C the specified role. When you apply
C to an object, the result is that the object's class is changed to a
singleton class that C its former class and C the specified
role. That is, you use C when you want the new role's methods to
take precedence over the existing class methods, and you use C when
you want the existing class methods to take precedence over the new role's
methods. In the case of C, you also need to be able to specify any
neccessary glue code (for conflict resolution, and/or to satisfy any
demands of the new role that otherwise wouldn't be satisfied).
> > > > Also: in the first of these two, would classof($thingie) actually
> > > > have to have Stringify as a role, or would it be reasonable to
> > > > instead say that classof($thingie) must meet Stringify's demands?
> > > > The latter would require more work on the compiler's part, but
> > > > would be considerably more flexible.
> > >
> > > I prefer the latter. I want to be able to compose requirements on
> > > the way. I certainly don't want to have to rewrite the core
> > > libraries (or extend them all) just to mix in an interface role that
> > > they already satisfy.
> >
> > In principle, I agree with you; in practice, it may not be workable.
>
> Verification should be just as easy for this as for a typed referenced
> parameter. I don't see why it wouldn't be workable.
It isn't neccessarily because validation would be difficult; although we
_are_ saying that validation would require you to do a point-by-point
comparison of the object's available methods to the role's available
methods rather than simply checking to see if the object's class has the
role itself[1]. Just as important as this point is the fact that
sometimes you'll actually want to validate against the literal presence or
absence of the role itself in the object's class, rather than whether or
not the class meets the role's demands - largely because roles can supply
methods as well as demanding them, and by asking for that role you're
actually saying that you want the class to use that role's semantics as
well as syntax.
Thus my suggestion that the default be that if you ask for a particular
role in a signature, it will match any class that does that particular
role; if you ask for something _like_ that particular role, it will match
anything that meets that role's demands whether or not it actually does
the role. So saying "($thing does Dog)" would require that $thing C
Dog; saying "($thing like Dog)" would require that $thing satisfy Dog's
demands. What you're asking for would still be available; just not
through C.
> > How would you handle the following:
> >
> >role Dog {must bark();}
> >role Tree {must bark();}
> >
> >class crossPerson {
> > method bark() {speak_sharply;}
> >}
> >
> >class Trog does Tree does Dog {
> > method bark() {bark_like_a_trog;}
> >}
> >
> >multi sub purchase(Dog $mansBestFriend) {...}
> >multi sub purchase(Tree $shrubbery) {...}
> >multi sub purchase($noisemaker must bark()) {...}
> >
> >my crossPerson $jack;
> >purchase $jack;
> >
> >my Trog $spot;
> >purchase $spot;
> >
> > Which, if any, of the subs should be called in each case? Or should
> > the compiler complain of duplicate definitions?
>
> $jack is a crossPerson, which absolutely does NOT have the Dog or Trog
> or Tree classes in its C chain.
Of course not; nothing will have Dog or Tree in their C chain,
because Dog and Tree are roles, not classes.
> If Dog and Tree are both "inferred" or "inferrable" classes, then the
> two multi declarations (Dog and Tree arguments) are identical.
In this example, there's no difference between the Dog and Tree roles;
however, this would almost certainly not be the case most of the time - at
the very least, a class with a Dog role would have @.legs, while a class
with the Tree role would have @.branches. However, if all that happens
when you specify a demand for the Dog role in a signature is that the
object must meet Dog's demands, then both crossPerson and Trog will be
accepted.
[1] It gets even messier because what you're really a
