A toy

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

status.c

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

tot.c

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.

chain.c

Generic chain-running idioms for the base-types defined by tot: interface in chain.h.

register.c

Preliminary fragments of a registration mechanism to let `types' register how they implement `interfaces'. Interface to this is in register.h.

lookup.c

some thoughts on `lookup' mechanisms, possibly to be integrated with register. Interface in lookup.h.

integer.c

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 ...

ankh.c

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.