Branden wrote:
>
> Edwin Steiner wrote:
> > Branden wrote:
> > [...]
> > >
> > > I also don't see how it wouldn't bang badly if we get an incorrect PMC.
> How
> > > would we extract the 5th element of a scalar? And how would we read one
> line
> > > out of an array? Sum two hashes? I think having only one vtable for all
> > > would only put a burden on who implements a vtable to croak an error on
> not
> > > supported types.
> >
> > You seem to be argueing against yourself here. If there is only one vtable
> > *layout* there will be no problem (at least no crash) if, say, the 5th
> > element of a scalar is requested, because the scalar *implementation* of
> the
> > responsible virtual function will deal with that gracefully (perhaps issue
> > a warning, or error).
> >
> > If there are different vtable layouts, very bad things might happen, like
> > calling a function with the wrong signature
> > (e.g. one argument instead of two args, ...) -> crash!
>
> Sorry if I didn't express myself well. What I mean is:
>
> In Perl, you don't have how to request the 5th element of a scalar. If you
> write $_[4], you are requesting the 5th element of the array @_. If you
> write $_->[4], you are first calling the DEREF_ARRAY on the $_ scalar, which
> is a scalar method, then asking the 5th element of the AV* returned by that
> method. If you write %a + %b, you are asking Perl to convert %a and %b to
> scalars, using the SCALAR entry of the vtable, or something like this, and
> then calling the PLUS entry of the scalar vtable to sum the two scalars
> returned.
I agree. It's because Perl is less orthogonal than eg. Python there is
more information (about how a value will be dealt with) passed from the
parser to the compiler -> bytecode -> VM. This is what I meant in another
post: "choosing the right opcodes for the job". I think this actually is
one argument against orthogonality: This way the programmer is forced to
produce more information about what (s)he wants to do.
I also don't see a way how a bad PMC would occurr this way. I think that's
why Dan called it a *minor* benefit if a bad PMC would not ruin anything.
Otherwise it would be an *essential issue*.
> What I mean is, the handling for the non-breaking on different types issue
> is handled on a layer above the vtables, the parser usually takes care so
> that FETCH is called only on an array, and PLUS only on scalars.
Right, as I said above.
> The fact of
> having only one vtable layout would, IMO, lead to two things: incorrectly
> calling a scalar method on arrays, or vice-versa, what wouldn't dump core
It doesn't really 'lead to' this, but it makes it possible, yes.
> but would certainly make the program die, what could be avoided if SV*, AV*,
> HV* and so on are different of each other, and casts are not required among
> them, as is done today in Perl 5,
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.)
> and the other thing is that creating a
> vtable for another type would break all existing types. Example: suppose we
> want compiled regexes (qr/^xyz$/) to have its own vtable so that we could
> inspect them and the regex-engine would interact with them by a clear
> interface. If we don't make it at first, adding them later would probably
> break scalars, arrays, hashes, and so on.
I get your point. But considering what Dan said about *not exporting vtables*
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.
> Yes, crashes (and dumping core) can happen in C if you are not careful and
> call a function with a wrong number of arguments, but so `printf' is as
> unstable as this.
That's why we like Perl's way to handle variable numbers of arguments
so much, right. :-)
> Actually this is safer, because if SV* never really
> contains an AV*, as happens in Perl5, you would never get a sv_vtable from
> an array, which would cause the crash you are talking about...
Right. I was talking about the case of only a single pointer type (PMC).
Both PMC and (SV*,AV*,...) have their pros and cons. Another advantage of
(SV*,AV*,...) is that the vtables would be smaller.
Dan favors the PMC single pointer according to his posts and I have the
*slightest* feeling that he knows a lot more about perl guts than me :-)
>
> Of course, I could be wrong, but your argument didn't convince me.
I think we agree quite a lot, maybe even in being wrong :)
>
> - Branden
-Edwin
