Introduction

[Armin Rigo]

Hello Slaters,

To put it short, I would like to help in Slate's development.

Let me introduce myself. I am a long-time programmer, and I have always
tried to push my programs in directions that seemed (to me) representative
as how all our software should work if it were not just 100% ad-hoc tricks
and tips. For example, my latest big project, QuArK (an editor for the
well-known game Quake, doing among other things 3D modelling --
http://www.planetquake.com/quark) contains features such as dialog boxes
built by code to match the available options; and a generic load-on-demand
file handling mecanism (e.g. the game, Quake, has a file format to store
an elementary file system; my editor can open and edit files inside of
this file system transparently -- it can actually edit any part of any
file transparently). This is nothing revolutionnary, but should let you
understand why Tunes' and Slate's more generic solutions to these problems
interested me. Besides, I am also a mathematician, so that I always look
for the most general solution to problems :-)

I proposed a modest programming system called "Bazar" some time ago.
Thanks to comments I received on it (thanks Lee) I can now define it
precisely with respect to other languages : it was a basically reflective
intensional variant of LISP with non-trivial strong typing.

More recently, drawing my way from Arrow to Pidgin, I mixed the latter
with some older ideas of mine to obtain something that is essentially just
the same as Pidgin, with other hard-coded foundations (and which I could
run and test to some extent). Here again I do not pretend that my work is
worth anything for Slate's own development, I am basically setting up
ideas for myself.

Let me introduce this in two words. Pidgin hard-coded a default format for
meta-objects (the "Map" class). I know it is supposed to be overridable,
but I fear defaults. They might eventually come in the way (e.g. you might
have to root any new meta-object on "Map", directly or not). But I know we
need a well-founded system !

I would like to point out there is another root that is in a sense more
natural. It is a default model for the concept of "algorithm". There is a
canonical (although not optimal) choice, which is the standard model of
the hardware itself : it is of course the executable machine code as the
processor understands it, as a plain sequence of bytes. No matter how
abstract you go in modelizing algorithms, you will have at some time to
translate some versions of them into executable code, so that this
particular modelization will always be useful.

Of course, the actual way this modelization is done is not the same for
different machines, and formally describing it is not only host-dependant,
but it can be rather complex; but this HAS to be done anyway. Also note
that I am suggesting that this modelization seems natural as the
foundations of Slate-like systems *on currently common hardware* only. I
don't know if something similar can be found, say, for programmable
processors; this modelization is canonical because it will always be
useful *and* because it cannot change (well almost -- I can guess you have
already found counter-examples, like upgrading a system).

In practice, this C++ code :

  http://homepages.ulb.ac.be/~arigo/rawmodels.tar.gz

implements these ideas by considering models as "point of views" on some
raw data, whose format is only understood by the meta-model. There is a
single special model that acts as meta-model for raw data which is a
sequence of processor instructions. (More precisely, it is a meta-model
for objects that modelize an algorithm on data that are processor code in
RAM.) Message sending (=slot lookup) is performed by meta-models and this
recursively causes other messages to be sent; the special meta-model
breaks this endless loop by causing the actual sequence of processor
instructions to be executed. (Note that the condition that this infinite
regression chain must contain an instance of the special model is not
restrictive, unlike similar conditions on, say, Pidgin's Map class;
otherwise it would mean that there is no compiled code that can perform
the requested operation, or invoke or build the requested code, or build
code that builds the code, and so on. Not a situation a processor can
handle, even with good software.)

All "sequences of instructions" in my test program are of course built as
a pointer to some static C++ function. Dynamically compiling for the
correct host requires more work :-)  And more importantly, I think that
models should first be developed to formalize the description of the
processor, before we implement compiling.


Anyway, all this is just some thoughts on foundations (didn't I mention I
was a mathematician ?). It doesn't help much Slate itself. But you will
admit that it is not so easy to know "from the outside" the most recent
developments of Slate :-)  No, no, don't flame me, we are all waiting for
Brian's update on this ! When this is out, I will try to see (and ask)
where I can help.

Thanks for reading me,
Armin