A6 questions
David Storrs
Ok, it took me several days to get through A6, and I'm not caught up
on all the mail yet (though I've tried to skim so I don't repeat
someone else's question). I'm left with a bunch of questions; can
anyone answer the following:
==QUESTION
- Page 8 says "In some languages, all methods are multimethods." I
believe that Java is one of these. Is that right and what are some
others? (This is really just curiousity.)
==/
==QUESTION
- Given the following code, what is called by $ride.current_speed()?
class Vehicle {
my $speed;
method current_speed() { return $speed; }
method set_speed($n) { $speed = $n; }
}
class Car {
submethod current_speed() {
print SUPER.current_speed();
return SUPER.current_speed();
}
}
class A6 { }
my $ride = new A6; # Perl with German engineering???
$ride.set_speed(60); # Calls Vehicle.set_speed()
print $ride.current_speed(); # Calls what?
[NB: an A6 is a type of car made by Audi; I couldn't resist.]
==/
==QUESTION
- On page 9, on the section concerning Rules, we see the following
quote:
"They [rules and methods] share the same namespace, and a rule
really is just a method with a funny syntax."
If that's so, why does there need to be a distinction between them?
Wouldn't it be better to use up as little mind-space as possible,
and reduce the required syntax set, by eliminating rules as a
separate type?
==/
==QUESTION
- Also on page 9, concerning macros:
"...while a macro's name may be installed in either a package
or a lexical scope, its syntactic effect can only be lexical,
from the point of declaration (or importation) to the end of
the current lexical scope."
Does that mean that I cannot define a bunch of commonly-used macros
in a single file and then use them in different files?
==/
====QUESTION
- SUPER:: is mentioned on page 9. Was this an analogy, or a
demonstration of intention to keep it?
==/
====QUESTION
- re: operator overloading, from page 11:
"...you may specify exactly where the parse rule is
interpolated with a special ... marker, which is considered
part of the name: macro circumfix:(*...*)"
If the ... is part of the name, then C<macro circumfix:(**)> has a
different name than C<macro circumfix:(*...*)>. What does that
mean in practical terms? Can I call them separately? If so, how do
I specify which one I want?
==/
====QUESTION
- Regarding <== and ==>:
list(@foo, how => 'scrambled' <== 1,2,3)
I had to read this a bunch of times before it started to make any
sense. What is happening here is that the 1,2,3 to the right of <==
constructs a list, and the list(...) constructs a list of everything
inside it. So a list is made of the 1,2,3, and that list is then
appended (via the pipe) to the list being built by the list(...). Is
that correct? And doesn't it meant that the <== is redundant and
obfuscatory?
Don't get me wrong--I LIKE the idea of piping operators, and I'm glad
they're here. I just want to make sure I understood what was going on
in this instance, and had't missed something.
==/
--Dks
----- End forwarded message -----
Chris Dutton
> ==QUESTION
> - Page 8 says "In some languages, all methods are multimethods." I
> believe that Java is one of these. Is that right and what are some
> others? (This is really just curiousity.)
> ==/
Doesn't C++ work this way? Also I believe Pike allows overloading of
methods by default.
> ==QUESTION
> - Given the following code, what is called by $ride.current_speed()?
>
> class Vehicle {
> my $speed;
> method current_speed() { return $speed; }
> method set_speed($n) { $speed = $n; }
> }
>
> class Car {
> submethod current_speed() {
> print SUPER.current_speed();
> return SUPER.current_speed();
> }
> }
>
> class A6 { }
>
> my $ride = new A6; # Perl with German engineering???
> $ride.set_speed(60); # Calls Vehicle.set_speed()
> print $ride.current_speed(); # Calls what?
Unless this is more complicated than I think, Car's current_speed() is
called.
That said, a minor nitpick is that you'd want something more like
class Vehicle { ... }
class Car is Vehicle { ... }
class A6 is Car { ... }
David Storrs
> On Sunday, March 16, 2003, at 05:09 PM, David Storrs wrote:
>
> > ==QUESTION
> > - Page 8 says "In some languages, all methods are multimethods." I
> > believe that Java is one of these. Is that right and what are some
> > others? (This is really just curiousity.)
> > ==/
>
> Doesn't C++ work this way? Also I believe Pike allows overloading of
> methods by default.
Nope. C++ will only dispatch on the type of the first argument (the
implicitly-passed argument which becomes the "this" pointer).
> > ==QUESTION
> > - Given the following code, what is called by $ride.current_speed()?
> >
> > class Vehicle {
> > my $speed;
> > method current_speed() { return $speed; }
> > method set_speed($n) { $speed = $n; }
> > }
> >
> > class Car {
> > submethod current_speed() {
> > print SUPER.current_speed();
> > return SUPER.current_speed();
> > }
> > }
> >
> > class A6 { }
> >
> > my $ride = new A6; # Perl with German engineering???
> > $ride.set_speed(60); # Calls Vehicle.set_speed()
> > print $ride.current_speed(); # Calls what?
>
> Unless this is more complicated than I think, Car's current_speed() is
> called.
I should have included the relevant quote (which I can't find right
now). This was a question specifically related to submethods. If I
understand correctly, submethods allow you to declare a method in a
base class, and override it in a derived class such that the
overidden submethod is not visible from classes derived from there on
down. So, if I'm right about this, calling $ride.current_speed() will
actually call Vehicle's method, because Car's is not visible (being a
submethod).
> That said, a minor nitpick is that you'd want something more like
>
> class Vehicle { ... }
> class Car is Vehicle { ... }
> class A6 is Car { ... }
D'oh! Yes, of course.
--Dks
Luke Palmer
> - Given the following code, what is called by $ride.current_speed()?
>
> class Vehicle {
> my $speed;
> method current_speed() { return $speed; }
> method set_speed($n) { $speed = $n; }
> }
>
> class Car {
> submethod current_speed() {
> print SUPER.current_speed();
> return SUPER.current_speed();
> }
> }
>
> class A6 { }
>
> my $ride = new A6; # Perl with German engineering???
> $ride.set_speed(60); # Calls Vehicle.set_speed()
> print $ride.current_speed(); # Calls what?
>
> [NB: an A6 is a type of car made by Audi; I couldn't resist.]
> ==/
Assuming the obvious inheritance, Vehicle.set_speed() would be called.
> ==QUESTION
> - On page 9, on the section concerning Rules, we see the following
> quote:
>
> "They [rules and methods] share the same namespace, and a rule
> really is just a method with a funny syntax."
>
> If that's so, why does there need to be a distinction between them?
> Wouldn't it be better to use up as little mind-space as possible,
> and reduce the required syntax set, by eliminating rules as a
> separate type?
> ==/
No. Rules fit better in a grammar than subs, and help the psychology
of people in various ways. For instance:
multi subst(Str $str: Rule $match, Code $repl) { ... }
Helps people to know that $match should be a regex. Helps the
compiler, too.
Also, it looks nicer:
sub identifier {m{ <[\w]-[\d]> \w+ }}
rule identifier { <[\w]-[\d]> \w }
> ==QUESTION
> - Also on page 9, concerning macros:
>
> "...while a macro's name may be installed in either a package
> or a lexical scope, its syntactic effect can only be lexical,
> from the point of declaration (or importation) to the end of
> the current lexical scope."
>
> Does that mean that I cannot define a bunch of commonly-used macros
> in a single file and then use them in different files?
> ==/
I think he talked about this in an appendix. You can export them, if
I recall.
>
> ====QUESTION
> - SUPER:: is mentioned on page 9. Was this an analogy, or a
> demonstration of intention to keep it?
> ==/
I think there was intention to keep it. It's a useful thing, you
know.
> ====QUESTION
> - Regarding <== and ==>:
>
> list(@foo, how => 'scrambled' <== 1,2,3)
>
> I had to read this a bunch of times before it started to make any
> sense. What is happening here is that the 1,2,3 to the right of <==
> constructs a list, and the list(...) constructs a list of everything
> inside it. So a list is made of the 1,2,3, and that list is then
> appended (via the pipe) to the list being built by the list(...). Is
> that correct? And doesn't it meant that the <== is redundant and
> obfuscatory?
I'm not too happy with the semantics of ==> and <==, but they might
grow on me... we'll see. Anyway, yes it is redundant. Just as
postfix C<if> is redundant with C<and>. It's still a useful thing to
have, in terms of readability.
And like most things in Perl, it can also be obfuscatory, given the
proper guise.
Luke
David Storrs
> Assuming the obvious inheritance, Vehicle.set_speed() would be called.
Ok good, that's what I thought. Thanks.
> No. Rules fit better in a grammar than subs, and help the psychology
> of people in various ways. For instance:
>
> multi subst(Str $str: Rule $match, Code $repl) { ... }
>
> Helps people to know that $match should be a regex. Helps the
> compiler, too.
>
> Also, it looks nicer:
>
> sub identifier {m{ <[\w]-[\d]> \w+ }}
> rule identifier { <[\w]-[\d]> \w }
I personally don't see a lot of difference between those two, but I'll
go with you on the "helps people know that $match should be a regex"
point. Good enough.
> > ====QUESTION
> > - SUPER:: is mentioned on page 9. Was this an analogy, or a
> > demonstration of intention to keep it?
> > ==/
>
> I think there was intention to keep it. It's a useful thing, you
> know.
Yes, indeed; I knew there would be SOMETHING that would fill this role
in P6. I just wanted to know if it would actually be the same token
with the same semantics, or if Larry had some plan to totally
hyperrenoberate how inheritance works and superclasses are accessed
(which he well may...we'll need to see A12, I suppose).
> > ====QUESTION
> > - Regarding <== and ==>:
>
> I'm not too happy with the semantics of ==> and <==, but they might
> grow on me... we'll see. Anyway, yes it is redundant. Just as
> postfix C<if> is redundant with C<and>. It's still a useful thing to
> have, in terms of readability.
>
> And like most things in Perl, it can also be obfuscatory, given the
> proper guise.
Good enough. I wasn't slamming the operator in total--I think it's
fine. I simply found this particular usage a bit awkward.
OTOH, I think this is wonderfully clear:
@data ==> map {} ==> sort {} ==> map {} ==> print;
--Dks
Matthijs Van Duin
>> sub identifier {m{ <[\w]-[\d]> \w+ }}
>> rule identifier { <[\w]-[\d]> \w }
>
>I personally don't see a lot of difference between those two, but I'll
>go with you on the "helps people know that $match should be a regex"
>point. Good enough.
Ehhh, I think rules need more magic than just m{} inside a sub to allow
proper backtracking semantics when it's used as a subrule
So that's another very good reason to make them different :-)
--
Matthijs van Duin -- May the Forth be with you!
Piers Cawley
> Greetings all,
>
> Ok, it took me several days to get through A6, and I'm not caught up
> on all the mail yet (though I've tried to skim so I don't repeat
> someone else's question). I'm left with a bunch of questions; can
> anyone answer the following:
[ list of 7 thematically unrelated questions, sharing only the fact
that they were sparked by the same Apocalypse ]
Okay, I almost put this into the summary, but it's really something
internal to the list:
Please, I'm begging you, when you have a bunch of questions about an
apocalypse which are otherwise only tangentially related, break the
list up into multiple posts. This thread is not the only offender by
far, but summarizing the responses to such a list is a complete
nightmare; I have to jump back and forth between posts, trying to
separate out the substrands so as to present something coherent. Or, I
just get pissed off with the whole affair and fail to do a good job of
summarizing. Also, if you split the questions up into multiple posts,
you have the opportunity to help me (and all other readers) still
further by coming up with meaningful subject lines for each
question. Trust me, a subject line of 'is static?' is way more useful
to the reader than 'A6 Questions' or 'Apoc 5 - some issues'. Also, if
you avoid 'grab bag' posts, you'll probably see more attention given
to your individual questions.
Make my life easier, go on, you know you all want to.
--
Piers
David Storrs
Apologies...I actually put them into one mail deliberately, because I
didn't want to burn more mindspace than necessary...people could skim
all my questions at once, answer those they were interested in, and be
done. I didn't think about how this would impact the summaries.
In future, I'll split questions as you request.
--Dks
Piers Cawley
> Piers,
>
> Apologies...I actually put them into one mail deliberately, because I
> didn't want to burn more mindspace than necessary...people could skim
> all my questions at once, answer those they were interested in, and be
> done. I didn't think about how this would impact the summaries.
I confess I've been bitten by the 'grab bag' thing before and didn't
sit back and notice that, whenever there was such a post, the summary
dealing with it got muddy. Your list of questions was the first time
I've actually thought about why that was.
--
Piers