Branden wrote:
[...]
> Edwin Steiner wrote:
[...]
> > Different pointer types also make coding harder when there is no
> > need to make a difference between object types. (When you just pass
> > something on, for example.)
> >
>
> I actually see it as strong typing, which I believe is good on the
> low-level. When there would be no need to make a difference between
> scalar/array/hash/filehandle/regex? If you're passing something on, at least
> in the Perl language, you can't call mysub($a), mysub(@a), mysub(%a), and
> expect them all to be in the same variable, so I don't see why this should
> be done in the low level. In contrast to it, you can call mysub(\$a),
> mysub(\@a) and mysub(\%a) and have them all in one scalar, but this could
> also be done with the DEREF of the scalar vtable. Of course in C you can
> always pass SV*,AV*,HV*,... as void*, and have all vtables have a special
> `type' entry (possibly the first one in the vtable), to make the cast back
> to SV*,AV*,HV*,... possible.
You got me there, I can't give you a specific example for indifferently
passing on something. Of course you could always cast to void*, which
leads to the second topic below:
As to strong typing: I don't expect that it will be possible on the
really low level. Of course it's no problem when calling C-functions
with arguments on the C-stack. But if you have a virtual stack machine
(Perl stack) or even convert to machine code (TIL) you loose type-safety
anyway.
I took the following from the Perl 5.7.0 source (pp.c):
PP(pp_av2arylen)
{
djSP;
AV *av = (AV*)TOPs;
SV *sv = AvARYLEN(av);
if (!sv) {
AvARYLEN(av) = sv = NEWSV(0,0);
sv_upgrade(sv, SVt_IV);
sv_magic(sv, (SV*)av, '#', Nullch, 0);
}
SETs(sv);
RETURN;
}
You see, while the Perl5 stack is a stack of SV*s it is used to hold
an AV* without any scruples. It really wouldn't make any sense to
wrap the AV* in a scalar ref just to call an opcode function.
So making sp an SV** is mainly for convenience because you don't have
to cast in the majority of cases, not for type-safety.
My point is that while it is perfectly possible to use different
pointer types it might not make much sense (at least not for type-safety
on the lowest level).
[...]
> > I wonder how many data types will directly rely on vtable layout. I would
> > think all data types implemented outside the core will use an additional
> > level of indirection (tie-like callbacks?). So maybe there will only be
> > a hand full of 'very internal' data types depending on the vtables.
>
> I actually don't see the need for having a `tie'-like interface. To me, at
> least, vtables are much more clear to deal with than a `tie'-like interface.
> Of course, we don't want to PMC->vtable[ADD][UTF_32](DEST, PMC1, PMC2);
> ourselves, but we could actually have a SV_ADD_UTF32(DEST, PMC1, PMC2) macro
> that would expand to that, and so on. Here the macros really buy us
> something... Having them implemented directly over the vtables, we won't
> have version-portability problems, and won't have to write that ugly piece
> of code either.
I thought of the `tie'-like thing because of Dan's:
" The vtable stuff won't be exposed outside the core. This means embedding
programs and extensions will *not* be using it. Generally speaking, it'll
be opcode functions only that'll be hitting the vtables. "
I don't really have a qualified opinion about it myself.
-Edwin
