paths from adt's to concrete bindings

11.7: adda/oop/paths from adt's to concrete bindings:

. it was pointed out that [everything is an object]

had been a selling point of some oopl's;

whereas, others had insisted that pure oop was inefficient .

. oop is a great way to simplify things for the app'designer;

but we don't need to make things easy on the compiler writer!

. the thing that makes oop`objects inefficient

is that the compiler is given no path to efficiency:

what can be statically determined about the object?

ie,

can it be proven that the symbol has

only the values of, and is accessed only by the operations of,

a binding to an efficient interface?

eg,

on most systems there is a binding to

hardware support for integer arithmetic

and if you can show that for some subscope,

a number really will be an integer,

than all calls can be bound to that hardware binding

rather than to the abstract type'mgt .

. of course for integers

this will be the first thing that adda does,

but it needs a way to do this for

an arbitrary binding .

. each type'mgt must have a way of expressing

a path to concrete types .

. imagine 2 interfaces:

one is all abstract, and the code is open:

the abstract procedures show how it

checks type.tags and value ranges

and maps these to the type'mgt's concrete calls library .

. the point of having your own language is,

given any platform and it's special mix of features,

be able to describe those features in your language .

. that doesn't mean a hal (hardware abstraction level)

has to be inefficient,

rather,

by asking the compiler to do more work (after the rad, of course)

programming to interfaces can be just as efficient

(in the best case of course,

compiler complication is a trade off with stability) .