Typing system vs. Java

[Alex Martelli]

"Markus Schaber" <markus at schabi.de> wrote in message
news:3187511.KiObB369e8 at lunix.schabi.de...
    ...[snipped: a summary of vtables]...
> And every function and attribute access means one pointer indirection,
> as the offsets of the members in the array are fixed - the types are
> statically known.

This is not sufficient -- the type must not just be statically known
(either declared or inferred), but *non-extensible* (not 'expando' in
Javascript terms, nonextensible in COM MIDL terms, not a Python
object in Python terms) or else dynamic lookup (which it may be
possible to optimize away via dispatch-caching, with some kind
of checking of course -- just as in the general case) is still needed.

A language might define rules whereby objects are "somewhat
extensible" but never in such a way as to require dynamic lookup,
but I suspect that would be pretty stilted, a typical case of a rule
made for the sole purpose of easing implementers' lives shows
through all the way up to language level and makes miserable
the lives of language _users_ -- typical of languages not used by
people who implement them, I suspect:-) -- in practice, we may
as well say that the ability to use vtables implies not just type-
knowledge (static or inferred) but also non-extensibility (either
imposed by the language or -- in very special cases, when ALL
relevant code can be seen -- again compiler-inferred).

> Even with caching, dynamic lookups will never be as fast as static
> lookups.

They'll be roughly as fast *when amortized*, typically in loops
where it matters.  Again, stalin and Self show us that.

> And with caching, you get in trouble when multi-threading:
> Imagine a method that signals another thread, and this thread replaces
> the method. But your own thread has cached the old method...

Clearly such "method modifications" must change the hashed type
signature -- remember I've stipulated a signature check before
the cached method is *used*.  I'd find it fun to see how a
"statically-typed" language would cope with a method changing
(and "in another thread" to boot?!-) 'under its nose'...?-)

> As long as Python doesn't allow self-modyfing code (means a block of
> code is immutable once compiled), it should be no problem (except
> implemenation effort) to replace the byte-code compiler with one that
> provides machine code.

Sure, a SMOP -- not that modifiable code would change that, there
would just need to be on-the-fly recompilation of the modified code
to machine code... still a SMOP!-)

> But this isn't the main slowdown - it is the dynamic lookup for every
> access. But when we change this, we wouldn't have python any more.

Except for some caching and possible optimization-inferences, of
course.  For example:

    for i in xrange(1000000000):
        a.pleep(i)

unless an a.pleep code changes the resolution of a.pleep (and I
don't think it would seriously violate Pythonic spirit to say that
has undefined consequences, just like today ensue from the far
more natural temptation of modifying a sequence one is looping
on:-), constant-expression hoisting could optimize this to:

    _temp_boundmethod = a.pleep
    for i in xrange(1000000000):
        _temp_boundmethod(i)

Of course, THIS can be hand-optimized without too much
trouble, too -- but consider:

    for i in xrange(1000000000):
        a[i].pleep(i)

Now, the Python coder is disarmed, even should he or she
know that all the a[i]'s are homogeneous in type (well, a
map of the unbound method on a might work, if the unbound
method can be gotten at -- maybe type/class unification
will eventually allow that for methods that don't belong to
a class... here's hoping!), while dispatch caching would help
a lot (if the a[i]'s belong to any of 3 or 4 types, in some
disordered sequence, then extended dispatch caching with
a cache of the last few method dispatches may be the
only practicable technique... I'd hate to hand-code THAT
in an application in any language!-).

> > I do.  Nothing will remove the need for extensions, although their use
> > may become less frequent.
>
> Fully agree. The only way to get around this is to have _very good_
> optimizing compilers, and to include every needed machine-specific
> detail as a language feature.

Unfeasible, since machines keep adding previously unforeseen
'details':-).

> If you don't include assembly into the language, you always will have
> to use extensions that don't follow the language's rules.

And if you do, you'll never be cross-platform.  I know which
'evil' I'd rather suffer... multi-language programming (why
do so many people hate it so?!) or having a supposedly high
level language become 100% tied to a specific model and
release of CPU...!


Alex