Sam Ruby <[EMAIL PROTECTED]> wrote:
> Leopold Toetsch wrote:
> My philosophy is simple: things without test cases tend not not get
> fixed, and when fixed, tend not to stay fixed.
There is of course a test case. I have mentioned it at least 20 times ;)
t/op/gc_13.imc - currently using lexicals.
> I am worried about Parrot trying to establish common public names for
> common functions. Many of the examples you gave did not include the
> prerequisite double underscores. For example: "sub", "imag", "eof".
Ah ok. Sorry. "__subtract". OTOH some might be that common and the usage
is the same in all languages that we might use that common name. But
that's probably not worth the effort. So yes, we should establish the
notion that all methods follow that convention.
>>>Re: VTABLES... I disagree with you on this one. Prematurely mapping an
>>>operation to a string is a premature pessimization.
>>
>> Except that we are doing that already. Please read through
>> classes/delegate.c. The problem is that this scheme doesn't work for
>> MMD of real objects.
> I don't know enough to have an informed opinion yet on MMD. But
> __set_integer_native is not a MMD operation. It already is efficiently
> dispatched to the correct method.
For PMCs yes. For objects not efficiently and only with a separate
delegate meta-class.
> ... What do we benefit from the premature
> pessimisation of mapping this to a string?
Well, method names happen to be strings ;)
Anyway, I'll try to summarize our current method dispatch scheme:
vtable MMD NCI method
-------------------------------------------------------------
opcode set P0, 4 add P0, P1, P2 io."__eof"()
-------------------------------------------------------------
PMC pmc->vtable->.. mmd_dispatch_* callmethod
object delegate.c 1) callmethod
object(PMC) deleg_pmc.c 1) callmethod
NCI methods are working, the method lookup is dynamic, inheritance
works.
MMD inheritance is totally static (set up during PMC compilation).
PMCs dispatch with the mmd_dispatch_* functions in ops/*.ops.
1) overloading a MMD infix operation needs the mmdvtregister opcode, but
this does not effect any class inheritance and it's just for the given
two types.
Multi-dimensional MD is not implemented.
For vtables objects and objects derived from PMCs use two helper classes
that bridge the dynamic inheritance of objects to the static inheritance
in PMCs. This doesn't support runtime overloading of methods that
defaulted to the PMC method.
Looking at 5 different schemes that work for ~50% of the cases can -
well - make one pessimistic ;)
I'm proposing that *internally* (implementation detail ...) one scheme
should be enough. Again: the opcodes don't change.
>> The vtable method set_integer_native clearly maps to a real method that
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> can be either inherited or be provided by the user. This doesn't work
>> for MMD functions.
> Again, set_integer_native is not an MMD function?
__set_integer_native is a vtable method.
>> No. I'm not ditching lexical pads at all. They are of course needed. The
>> top pad is in the registers. Outer pads are looked up as usual.
> I guess I don't understand. I guess it is time for a test case. ;-)
> How would the following work if the top pad is in registers?
The top pad is always the currently executing one.
> var = 1
> def g():
> global var
> var = 2
> print "before", var
> g()
> print "after", var
It's obviously up to the "global" to do the right thing. My impression
(I don't have more Python knowledge ;) is, that "global" refers to the
outermost lexical pad in the main module.
> Such behavior is the default for perl5:
> my $var = 1;
> sub g {
> $var = 2;
> }
As there is no "my $var" in the inner pad, that's just a C<find_lex>
opcode. It follows the C<prev> pointer to the outer pad and finds in the
lexical hash the "$var" which maps to a position in the register store
of the outer pad.
"my ($a, $b)" in the innermost pad (in sub g) would map directly to
registers as "my $var" maps to a register in "main" (in the outer pad).
It's the same as currently, except that we have now a separate array
that holds the lexicals. I was just mapping that array into the
preserved area of registers, which would make this area of course
variable-sized with the nice benefit that "my int $i" also works (we
don't have natural int lexicals currently).
> - Sam Ruby
leo
