RE: Mutil Method Questions
From: Steffen Schwigon [mailto:[EMAIL PROTECTED]
Thomas Wittek [EMAIL PROTECTED] writes:
Maybe we should steal the ruby principle of least surprise here,
which I find a very good principle.
I'm quite confident that Larry already stole all good principles he
could find.
Me too. However many ongoing discussions on #perl6 and in
perl.perl6.language involve how to better reconcile such principles.
(Thanks especially to Pubs, which has stimulated a great many
refinements and improvements in the Perl 6 language, and continues to
do so.) So I think the previously expressed sorts of general concerns
are valid, even if there turns out to be {other overriding technical
issues, or some sort of misunderstanding} in this particular case.
If there would be a Full Metal Perl movie, the imdb
quote collection would contain:
These are great days we're living, bros. We are jolly green
giants,
walking the Earth with Perl6.
Good start
These principles we stole here today
are the finest principles we will ever know. After we rotate back
However Finest principles known now is extremely likely a
subset of finest principles we will ever know (especially
considering how relatively recently most were discovered, and
especially if you live at least another 10+ years). One *huge*
advantage of Perl 6 is to make it *much* easier to copy *new* great
ideas as they come along. I think that one of Perl 6's greatest design
principles is to anticipate discovering new great design principles.
to
the world, we're gonna miss not having any principle around that's
worth stealing.
Oh yea? What about Perl 7!? :-)
I expect that Perl 7 will have at least 1 or 2 new finest principles
that will be back-ported to Perl 6. My wild guess is that an early
perl7 production prototype will be available around 2020.
But I think it's a big mistake to get too stuck on specific Perl
version numbers, versus featuring the evolutionary role and trajectory
of Perl: Perl++, the most natural language of software progress;
featuring CPAN++, the executable Wikipedia of software expertise.
(This generic designation also has the virtue of reminding people that
the other branch of Perl is also evolving, with Perl 5.10 well along
in the works, and Perl 5.12 seems a very likely follow-on prospect.)
Best regards,
Conrad Schneiker
http://perl.net.au/wiki/Perl_6_Users_FAQ (Moved from AthenaLab to Perl
6 Wiki.)
www.AthenaLab.com (Nano-electron-beam and micro-neutron-beam
technology.)
Re: Mutil Method Questions
Thomas Wittek [EMAIL PROTECTED] writes:
Steffen Schwigon schrieb:
At least the many keywords seem to be necessary to map the complexity
of different paradigms possible in Perl6. Multimethods are not just
overloading as in C++. Second, the different keywords declare
different behaviour you can choose. Just read S06, it's explained
quite understandable.
Hm, but wouldn't whose be equivalent?
sub foo ($bar) {
$bar.say;
}
multi sub foo ($bar) {
$bar.say;
}
Aren't subs a subset of multi subs, meaning that every sub can be
expressed as a multi sub?
Is there anything a sub has in advantage of a multi sub?
So might not just every sub be a multi sub?
If the only difference is, that you _must not_ declare a sub twice with
different argument lists, I think that this one is relatively
unimportant and letting every sub be a multi sub seems to be more
consistent to me in opposite to this arbitrary looking distinction.
Maybe I just phenomenally misunderstood multi subs, but unless I
did, I can't see why we want to have subs when we can have multi
subs that can do the same and even more.
I understand your point and I confess I'm not sure.
At least there seems to be a visibility difference. In S12 I found
those two sentences:
1. [sub (or method) without a multi] [...] Only one such sub (or
method) can inhabit a given namespace, and it hides any outer subs
(or less-derived methods) of the same short name.
2. [subs or methods declared multi] [...] It does not hide any
routines with the same short name but a different long name. In
other words, multis with the same short name can come from several
different namespaces provided their long names differ and their
short names aren't hidden by a non-multi declaration in some
intermediate scope.
GreetinX
Steffen
--
Steffen Schwigon [EMAIL PROTECTED]
Dresden Perl Mongers http://dresden-pm.org/
Re: Mutil Method Questions
On Fri, Jun 23, 2006 at 06:18:51PM +0300, Markus Laire wrote:
multi sub talk (String $msg1, String $msg2) { say $msg1 $msg2 }
multi sub talk (String $msg, Int $times) { say $msg x $times; }
multi sub talk (String $msg, Num $times) { say Please use an integer; }
multi sub talk (String $msg, Range $r) { say $_: $msg for $r }
talk(Hello, World); # String and String
talk(Hi, 2); # String and Int
talk(Test, 1.23); # String and Num
talk(Hello, 3..5); # String and Range
talk(123, 3); # Int and Int
I think that would print
Hello World
HiHi
Please use an integer
3: Hello
4: Hello
5: Hello
123123123
In last example, there is no exact match for parameters (Int, Int), so
IMHO perl6 would select the closest match, which in this case is
(String, Int) because Int can be converted to String.
An alternate interpretation would be that the last one is actually a compile-
time error because none of the sigs match (Int,Int) and for a call to
work with 2 Int parameters, you'd need to be explicit:
talk(~123,3);
But I'm not sure which way perl6 actually leans.
Though it seems to me that automatic type conversion by the compiler is
a way to get yourself in trouble. Not that perl shouldn't let the
programmer get himself in trouble, but this seems like one of those
things that should require asking to turn on rather than asking to
turn off.
my two cents,
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
