Typing system vs. Java

Bengt Richter bokr at accessone.com
Sun Aug 12 23:19:11 EDT 2001


On Sat, 11 Aug 2001 01:54:43 +0200, Markus Schaber <markus at schabi.de> wrote:

>Hi,
>
>Bengt Richter <bokr at accessone.com> schrub:
>
>> E.g., what if there were a 'restricted' keyword (or you pick one ;-)
>> which allowed the compiler to assume that a function's arguments would
>> always be the same types as in provided default arguments, and that
>> there would be no global side effects, and global references would be
>> stable as to type? It would seem you could allocate local working
>> storage on the stack and avoid reference counting and lookup to a
>> large extent.
>
>But you can't save the lookups between different objects of the same 
>type, because "same type" means "same interface", not "same 
>implementation".
>
I had in mind an *ignorable* hint to the compiler, so that *some* platforms
could *optionally* generate platform-specific optimized code for restricted
kinds of function definitions or expressions. Since this would be specially generated
for a particular platform, "same type" could presumably  be restricted/coerced
to "same representation type". E.g., it should be possible to generate
extra fast code for evaluating a polynomial expression, without writing an extension.

One could even imagine an optimization mode that would speculatively (no hints in code)
produce optimized code for an inferred situation with fast checks to verify assumptions
and go ahead if ok, and non-optimized code to handle the case if not. There could
be an optional dictionary of compilable entities with optimization levels/info
that the compiler could check if present (which would amount to externalized hints).

>And trickery with the reference counting may get you into problems when 
>using multithreading. Assume, you don't increase the reference count 
>for local variables - than another thread may kill the last counted 
>reference, and the object is freed erreaneously.
>
For what I hand in mind, a restricted function would be stateless and
reentrant, so different threads would get their own local storage.
For global references (immutable objects only), I imagine reference
count would be incremented at compile time, and decremented when the
compiled code object was deleted, not at execution time. Suitable
global mutable objects could be copied at compile time, with that
understanding.

If you were writing multi-threaded stuff that depended on non-reentrant
semantics, you wouldn't be able to use the restricted hint. I don't
mean to say that that absolutely couldn't be loosened, but just
to start somewhere.




More information about the Python-list mailing list