Model

[Jordan Henderson]

BRIAN SPILSBURY writes:
> 
> LispOs: a Model
>

[Much really great discussion snipped. This is really great stuff,
not just principles and buzzwords, but specific proposals about 
architecture.]


> -- now for a couple of whinges --
> 
> What is this scheme/CL debate? Neither langauge is appropriate as a core
> to an os. Write a micro-lisp with reflection and mop, and then if you feel
> the need implement CL/CLOS/Scheme over the top, also add in security
> (preferable though something lispish like _capabilities_, rather than
> unix flavour silliness), and threads are a must.

I hesitated to bring this up here.  I feel it will probably get shot down
pretty thoroughly.  How about ANSI Forth (with much extension) as the low
level core (and ultimately the implementation language for whatever Lisp
is chosen, until the Lisp compiles itself and we can throw away that 
compiler).

Advantages:

  - Many of today's machines (Sparcs, PowerPCs, some PCI-bus machines)
    come with a full ANSI Forth core in the OpenBoot Firmware.  There
    will be for these machines complete low level diagnostics and some
    primitive kind of device driver available for all supported 
    devices.  Those machines without OpenBoot Firmware could be made
    to quickly load an ANSI Forth core.   

  - Forth is well known to port very easily and runs in all kinds of
    environments.  If the LispVM were implemented in Forth then we
    could quickly bring it up under various OS's, standalone, have
    real-time subset implementations for embedded distributed 
    applications, etc. etc.  A portable Forth like GForth (GNU)
    could be used for initial ports.  One report I read recently was that
    2 guys brought up GForth in a new embedded environment on a
    new machine architecture in a weekend.  Now, they feel with the
    work they did to simplify the porting, it could be done in an
    >afternoon<.

  - Writing the VM in Forth will not necessarily mean that we have another level
    of interpretation making things unbearably slow.  There are good 
    compilers for Forth these days that rival compilers for other languages.
    Also, the factoring typically found in well written Forth leads to
    ease of hand optimization.  Forth typically includes direct assembly
    language support, so it will be possible to improve it on a micro-
    optimization level.       

  - The interactive development environment fits in well with the typical
    Lisp mindset of incremental testing and development.
 
  - Mop systems have been implemented in Forth and seem to work quite well.
    Reflection seems possible, but I don't know of any practice along these
    lines.

Disadvantages:

  - Including threading support might be tricky in any portable way.

  - Lisp people often disdain Forth and vice-versa (I suspect family
    rivalry among languages with interactive environments included).

  - Forth scales poorly, but I do propose getting to a Lisp language
    fairly quickly.

> --
> 
> Feel free to flame, anything will be better than the 'what name will we call
> this os that we haven't even defined in any way more than an os that is
> lispy', or the 'I want Scheme! I want CL! I want GCC!' threads.

I agree with this and apologize for all the contributions to the silliness
I may have made in the past.  I did think the name thing was important to
give us a rallying point and focus.  Now, I think things will coalesce in
their own time.  I still would like to see a project coordinator spring up.

> Brian Spilsbury
> 
>