Back in 1985, Malcolm Sabin had an idea running around inside his head, related to a scripting language he dreamed of for a finite element system. Nowadays it'd be described as object-oriented. He also wanted everything in the system to be of one kind. He had some ideas on how to go about that. He had, however, no time in which to do it. Too many meetings, etc. So he hired a student (me) to work on it for a summer.
Malcolm taught me a lot in the course of that summer, and the idea got into my head. We arrived at the conclusion that (at least in ForTran or basic, the languages we were using) it just couldn't be done, but it had been interesting trying. The quiet conviction that it deserved to be possible never stopped nagging at the back of my mind.
In the middle of December 1998, I got involved in a discussion about python's type system. In the course of saying a few things that came naturally to me, I tripped over some thoughts which avalanched into a solid conviction that I'd found how to do what Malcolm had in mind. Now what remains is the writing of it. The midwinter break gave me a chance to make some progress on that, but I've allowed myself to be distracted by other matters awhile. In the winter of 1999/2000 I gave further thought to the implications for python of where my December 1998 thinking leads; two winters later I returned to the pythonic side of the topic for some more fiddling, but whether I'll ever make progress on the engine I dreamed up is another matter.
One of the basic ideas behind my intended solution is to hang a bunch of (mostly static) functions off suitable static structures to form an entity which, used in accord with some simple protocols, does `enough' to make it possible to build everything else.
The existing fragments (as at - see Id line at foot of this page) run to
Builds a noddy status handler mechanism sufficient for throwing and catching. Its underlying type is defined in status.h and is essentially similar to the type defined in tot.h. Further waffle in status.html
will be the home of the central tools when I get back to it. The types defined in tot.h are the basis of everything that matters.
Generic chain-running idioms for the base-types defined by tot: interface in chain.h.
Preliminary fragments of a registration mechanism to let `types' register how they implement `interfaces'. Interface to this is in register.h.
some thoughts on `lookup' mechanisms, possibly to be integrated with register. Interface in lookup.h.
Preliminary thoughts on how integers will be packaged, with interface integer.h. For floating point types I'd ideally like the constructor to be told the implicit error-bar one infers from the number of digits given ...
A sketch of how allocation will happen, with interface ankh.h
The comments say more, might even be intelligible. In places.
wc *.[ch] 178 893 5640 ankh.c 19 87 566 ankh.h 85 393 2558 chain.c 71 464 2915 chain.h 82 232 1592 integer.c 7 16 124 integer.h 119 476 3140 lookup.c 47 330 1975 lookup.h 57 294 1961 register.c 76 591 3705 register.h 262 1295 8167 status.c 99 592 3710 status.h 19 79 488 tot.c 109 728 4335 tot.h 1230 6470 40876 total
Note: python-specific discussion I've moved to one side.Written by Eddy.