[Types-sig] attempted summary

[Edward Welbourne]

OK, so I'm getting a clear enough view of where I'm going that I can say
the things that seem to be relevant to where I started (which is
python's type system) rather than where I'm going (which is the
completion of A Quest that I was Given when I was an apprentice).

The tone of the types/classes/meta discussion was all pointing at the
fact that attribute lookup is the cornerstone: if we can just do that,
we can do everything (eg take the object you want to involve in
addition, look up its addition attribute, use that to do addition: all
we needed was attribute lookup).

Well, of course, we also need function invocation or we can't do that.

Now, it so happens one can formalise searching (eg attribute lookup) as
exception handling.  Roughly, this formalism looks at the code we use to
do attribute lookup and views it as *a piece of computation which is
meant to achieve nothing* but if you happen to find the attribute during
lookup, you raise the IveFoundIt exception, which the lookup wrapper
catches, and the rest of the futile computation gets skipped because an
exception was raised.  If the futile computation runs to completion
we're then (perhaps to the formalism's surprise) disapointed: we
probably raise IhaventFoundIt, which we're more used to viewing as an
exception.  I hope at least the perverts among you will enjoy that
thought - I certainly did when it caught my attention.

So I'm going to do attribute lookup as exception handling: furthermore,
the way I'm going about exception handling is to have a chain of
exception handlers *on the stack*, each pointing `up' to one further up
the stack than itself, right back to the ultimate handlers which are
static and hang off the top of the chain.  When an exception gets raised
it *immediately* takes a journey up the chain to find whoever is going
to catch it, negotiates with them and returns control to the context who
had the problem.  It passes enough information back to this context to
let it

either pretend none of that ever happened (exception resolved)
or know that something has gone wrong and return to its caller

In the latter case, the exception handling will have adjusted the
handlers on the stack so that they all tell their contexts to give up as
control returns to them, until it gets back to whoever caught the
exception, who will (presumably) do something about the mess.  I'm a bit
vague about what gets returned by the functions which are returning
here, but the crucial thing is that the exception handler can have
transcribed some data from the exception it handled to the handler (or
some record known to it).  So the value found by the lookup is `passed
back' to whoever asked for it *and then* the code which found it
abandons what it's doing, as if in response to an error.

Anyhows, we end up needing only function invocation and error handling.
For which I have a `good enough' very simple model which will let me
bolt everything in via the namespace lookup that the handlers can fake
up for me.  In this model, every `record' consists of a structure whose
first field is a *function* (in the implementation language) which is
known to other functions from the same *compilation unit* as it.  The
record may have other fields (in which case that compilation unit had
better know about this and be sure not to install the wrong function on
the wrong record type, because the *central system* knows nothing about
all this `cheating' that each type does), but the central system never
attends to them.  (Well, of course, the central system is a compilation
unit, too, so the records for which *it* is responsible may have such
extra fields as it cares for, so long as it puts the right functions on
them.)  The function serves as a `type' but only its compilation unit
*really* recognises it ... though other compilation units may own
lookups in which they can find tools with which to manipulate records
carrying that function.

Beyond that, the fiddly bit (that I fanatically Believe I Can Do but on
which I realise I might get stuck) is the building of a bunch of static
data structures, with functions hanging off them, which will constitute
(at compile time, in practice, though there will be some dotting of i
and crossing of t to do as a runtime initialisation) a lookup/exception
handling engine with enough machinery on board to let other modules:

 register interfaces, behaviours and (most important of all) some rather
 more sophisticated tools for doing lookup efficiently (but carefully
 disguised so the system never realises that's what they are).

 ask it for things registered with it, ie do lookup

and I'll be back to that on Friday, when I break from work 'til New Year.
I'm expecting that by the New Year I'll either have discovered what I've
failed to notice thus far, or have solved a problem that's bugged me for
13 and some years.  Manic but happy ;^>

My toy implementation's current fragments are at 
	http://www.chaos.org.uk/~eddy/craft/tot.html
but I'm afraid there are some typos in the links.  The second tot.c
should say zot.c, but fortunately its href is right; ankh.c is right but
its link says anhk.c so doesn't work; and I forgot to mention zot.h and
ankh.h, which are also there.  This page will evolve as I progress.

	Eddy.