[self-interest] OSes (was: Patterns in Self)

[Thierry Deval]

Hi Jecel,

Sorry for the long Cut&Pasto, my (few) comments lie at the end...
(Jecel, you write a lot, but it's a pleasure to discover Self thru your words ;-)

On Saturday, December 2, 2000, at 07:20 PM, Jecel Assumpcao Jr wrote:
...
>    Self in Self - no need to deal with C++ compilers and development 
> environments. I'll add a copy of part of an email Craig Chambers sent
> to this list in 1990 about the problems of having a Self compiler 
> compile itself, but I still think it is a good idea. Another way in 
> which Self/R is written in itself is in having "narrow interfaces" to
> the underlying system: the graphics system show do everything in Self
> (fonts, ovals, etc) and just use the libraries in the OS (if there is
> one at all) to blast the final bits to the screen. The good part is 
> that porting becomes much easier and you don't have to keep dealing 
> with other people's bugs (Self 4.0's dates were very broken in 
> Solaris 2.5, for example. I tried to fix them but found that all the
> work was being done in Unix and I couldn't touch it) and the bad part
> is that you make no use of all the effort people are putting into
> other programs (in the example I gave, dates started working
> perfectly in Solaris 2.6 without me having to do anything). 
>  
>    Reflection - systems written in themselves can be very dangerous. 
> Just see how easy it is to break Kansas. Can you imagine if you could
> rewrite the garbage collector while it was running? Squeak doesn't
> have this problem because the system you are changing and the system
> that is running it are separate (the problem is that transfering your
> changes from one system to the other after you are done is slow and
> awkward). 
> In Self/R you get the best of both worlds by having the base level 
> objects supported by multiple meta level objects. So if you break 
> something while trying to write a new garbage collector, the whole 
> system won't come crashing down on you but enough of it will continue
> to run (using the old, unmodified meta objects) to allow you to fix 
> things. This is rather like Kansas opening up a new window in which
> you can use the debugger whenever the old window breaks too badly. 
>  
>    Distributed Persistent Object Store - this is an alternative to 
> Snapshots and the Transporter. It is also an alternative to the
> virtual memory in the OS. Your objects are automatically swapped
> to/from disk in "clusters". A version system allowed you to back up
> whenever things seem to have become corrupted. I won't go into more
> details here, but it is interesting that the new Groove software
> (http://www.groove.net) has some features in common with my design.
> The important thing is that, when running on top of another OS,
> Self/R can be lightweight by only loading the clusters actually
> needed to run a given application. These clusters are also the key to
> making it easy to distribute Self/R - if someone attaches one to an
> email they send you, it will be simple to get the components you need
> to see it on your machine (like getting Acrobat Reader when you run
> across your first PDF file). 
>  
> So, what do you people think. Are these things worth having? 
>  
> -- Jecel 


I have to agree for the usefulness of a "Self"-contained language, this has been one of the driving force for popular languages like C/C++ or Forth.

Of course, these languages had sufficiently low-level features to be able to contruct the machine-code bytestream and even develop some code optimizing logic. But I don't see why we couldn't do it in any other language like Self. BTW, Self already relies on VM-like bytecodes, so why couldn't we implement the logic of the bytecode to machine-code translator in Self ?

Regarding the implementation of a Self-in-Self compiler, I like Forth's approach (back from Forth83) : meta-compiling.

They first built a small assembler/code-generator which could then parse the System sources and build a new runnable environment in a separate Dictionary. (a parallel World in Self)
The new Dictionary was then saved as a runnable, executable image... This could also be used for cross-compiling...
All of this needed only a small compliant Forth micro-kernel and the sources, for bootstrap; the micro-kernel could have been written in any other language, or even in Forth...


Having Self rely on itSelf is the necessary step to have a SelfOS, with proper HAL and device driver Objects, probably with a well laid OS/Device framework of building blocks. (did we talk about architecture lately ;-)

my €.02

  Thierry (an enthusiast)