David Mitchell <[EMAIL PROTECTED]> writes:
>The problem is "what are the (types of) the arguments passed
>
>I dont really see why types af args are (in general) a problem.
Hmm, you may be right at the level of your example, which may indeed
be typical of pp_xxxx(). Perhaps PerlIO is so bother some because it is
lower level. If all the args are SV * (or whatver perl6 calls it)
then there is no big deal.
>pp_concat() {
> SV *sv1, *sv2;
> sv1 = POP; sv2 = POP;
> sv1->concat(sv2);
>}
>
>the_type_of_sv1_concat(SV *sv1, *sv2) {
> if (sv1->vtable == sv2->table) {
> // both args are of this type:
> // dive into the internals and do an efficient concat
> sv1 = ....;
> } else {
> generic_concat(sv1,sv2);
> }
>}
The two "snags" with that are (and they may not be important):
1. One point of the vtable scheme was to avoid conditionals following
memory fetches.
2. The else branch may be very common, so we just added a function
call and a test to the "normal" case.
The snag is that there are common pairs
e.g. concat(utf8,ascii) / concat(ascii,utf8)
or
plus(NV,IV) / plus(IV,NV)
where it is possible to get "smart" when one arg is a "special case" of
the other.
>> True, but the messy details would now occur multiple times,
>> as soon as substr_utf8 exists then _ALL_ the other string ops
>> _must_ be overridden as well because nothing but string_utf8 "class"
>> knows what is going on.
>
>perhaps I'm being dim, but I dont really follow this. At the minimum,
>someone writes a generic substr function that works with any string types.
>Perhaps it achieves this by first converting all its args to UNICODE-32.
So we presume that all string types MUST (in standards-ese) support
a ->toUNICODE32() method?
And similarly numbers must be convertable to "complex long double" or
what ever is the top if the built-in tree ? (NV I guess - complex is
over-kill.)
It is the how do we do the generic case that worries me.
>Not very efficient or desirable, but it gets you there.
>Then the implementor of the utf8 code writes a substr_utf8 function that only
>knows how to cope if all its args are utf8. If not, it just
>hands the call on to the generic sub.
I see that now it is more flexible that what we "sort of have" to-date
which is like:
>pp_concat() {
> SV *sv1, *sv2;
> sv1 = POP; sv2 = POP;
if (sv1->vtable == sv2->vtable)
> sv1->concat(sv2);
else
generic_concat(sv1,sv2);
}
Or perhaps :
>pp_concat() {
> SV *sv1, *sv2;
> sv1 = POP; sv2 = POP;
if (sv1->knows_about(sv2->vtable))
> sv1->concat(sv2);
else
generic_concat(sv1,sv2);
}
Both of which either pre-judge waht is allowed or put cost on the
front of the simple case.
>> >In fact, I would argue that in general most if not all the operations
>currently
>> >performed by pp_* should have vtable equivalents, both for numeric and string
>> >types (including unary ops, mutators, binops etc etc).
>>
>> Hmm - that is indeed a logical position.
>
>logical as in "consistent" or logical as in "sensible" ??? :-)
Consistent. Consitent is usually sensible though.
>
>I was under the impression that it was pretty much agreed for numeric
>types that each SV type would have its own set of binary ops (eg add, sub
>etc), so I wasnt aware I proposing anything radical!
We have not solved (or I have not spotted) what you do
when you get IV * NV. Something has to "know" to "upgrade" IV -> NV
and call NV's '*' - which does not scale well.
>I can't see why you get a code explosion. In perl5 you get the explosion -
>every part of perl needs to know about every SV type, and introducing a new
>type or subtype involves hacking in just about every nook and cranny within
>perl.
>If there was a bug in the + operator, it would be apparent fairly quickly
>where it lies (eg int+int and num+num gives right result,
>int+num goes wrong; therefore the Int->add[NUM]() function is suspect.)
All true.
The explosion is that you have
Int->add(Int)
Int->add(Num)
Int->add(Rational)
Int->add(Monetarty)
Int->add(NumComplex)
Int->add(IntComplex)
Int->add(RationalComplex)
Int->add(InternationalMonetary)
Int->add(String); # containing any of above
Int->add(OverloadedObject)
Or if Int doesn't do that then generic_add() has to.
etc. - perl5 we have IV,(UV),NV so the problem is bounded.
>> In other words - string ops on strings of uniform type, math ops on
>> well understood hierachies etc. are all easy enough - it is the
>> combinations that get very messy very very quickly.
>
>I couldnt agree more - however, I think that issue is mostly orthogonal
>to whether most pp_ functions should have vtable equivalents. If the
>functionality is built dirrectly into pp_XXX, you still have a combinatorial
>mess to cope with - hiving off into vtables *may* reduce the mess, or
>*might* increase it, depending on how its done.
If it "depends" then it isn't strictly "orthogonal".
>
>One final thing - I'm fairly new to this game (I thought the start of Perl6
>would be a good time to get involved, without having to understand
>the horrors of perl5 internals in depth), which means I run more of a risk
>than most of speaking from my derierre. So far I have been reluctant to
>put forward any really substantial suggestions as to how to handle
>all this stuff, mainly for fear of irritating people who know what
>they are talking about, and who have to take time out to explain to me why I'm
>wrong! On the other hand, I do seem to have ended up taking a lot about
>this subject on perl6-internals!!
>So, should I have the courage of my convictions and let rip, or should I
>just leave this to wiser people? Answers on a postcard, please....
We old'ns need people that don't know "it can't be done" to tell us
how to do it - but we reserve the right to say "we tried that it didn't
work" too.
--
Nick Ing-Simmons
