[long] Re: MOOSE project -- looking for a language

[Karl Czajkowski]

In article <94-10-147@comp.compilers> you write:
>  As I'm sick of computing systems I know, and saw no end to them, I've
>decided to write my own, on my 386 PC to begin with, but in a portable way
>(have an implementation over *yuck* POSIX ?).
>

God, do we all get this impulse? :)


>  I'm still looking for the High-level language to use, which must be able to
>integrate all the features described below. Can somebody help me ?
>  I'm considering BETA, SELF, Icon, or something like that. Else I'll have to
>design my own (as a self-extended typechecking FORTH-like thing ?) :( :(; but
>as our moderator say, the world is not ready for yet another language, so if
>I can skip the language design phase, I'd be very happy.
>

Scheme... Well, at least don't engineer stacks into the system at too low of
a level, because that makes it really hard to support non-stack based
languages like Scheme efficiently--take unix, *PLEASE*! :)


>
>  The project is called MOOSE, and I'm writing it alone. It means
>Multi-* Object-oriented Operating System and Environment. *I* didn't choose
>the name as I wasn't alone at that time.
>
>  It's a project for an OS that will change you from Un*x and
>sub-clones like MS-DOG:

Hmm, I wouldn't count on changing anyone from unix until it provides a
compatibile environment to use all the old code out there with reasonable
performance.  This means to me that gcc/g++ would have to be ported, and I
don't think that would not be easy to an environment like your suggested one
which changes the semantics so much.  I am not throwing rocks, but I have
thought about doing these same things at various times and these are some of
the issues that have stopped me cold before I got too excited.


>- of course multi* (tasking/threading/user)
> This implies a language not centered toward global variables (no "C"), with
> an ability to understand concurrency (with current-continuations ?).
>
>- persistence, thus garbage collection, security, type-checking
> (thus again no "C") that means no *need* of file system (but still support
>  them to communicate with other OSes.
> That also means *need* for a language that supports secure type-checking and
> orthogonal persistence.
>

I think that a file system would be prudent even in a "modern" OS, and not
just as a means to communicate with other OSes.  If nothing else it could be
a hidden module inside the system to abstract things like caching and
device-interfacing for slow external storage.  Once it is there, a
unix-clone module could use it...

I once considered making all of the external storage virtual-memory as a
quick way to get persistence, but then realized how attrocious the
performance would be without more organization and structure over the
storage space to provide for locality and caching.


>- machine-independent low-level (stack-based/FORTH-like ?) language for
> portable binaries, with common interpreter or compiler back-end.
>  This implies nothing for the HLL.
>

I would definitely think something could be lifted from another distributed
OS project for this; perhaps Sprite has something to offer here?  Another
alternative is to transmit the HLL and recompile, which would leave more
network bandwidth for other data transmissions.  A fast compiler with fewer
optimizations would be required, and a good scheduling heuristic to
determine whether it would really be faster to migrate under whatever
migration schemes are available.  Maybe a module would get profiling-info
tacked onto it to help the scheduler?


>- partial lazy evaluation and optimization for ideal dynamic performance
> This implies a HLL with lazy evaluation semantics.
>

Scheme has this... (delay/force constructs)


>- no-kernel (not even micro- or nano-) architecture. Everything is
> decentralized in modules (even the module loaders). The only thing needed
> is a boot module. Modules communicate through conventional protocols (which
> may change by replacing all concerned modules).
> This implies the existence of a good module system for the HLL (unlike
> the C header file bullsh*t).
>

Isn't it a bit rash to toss the whole kernel out the window?  Doesn't
something need to exist which syncronizes and controls access to the actual
hardware?  I tend toward the idea of asyncronous messaging between the
various modules and the hardware manager; all of the modules see a
virtualized, abstract interface and only the manager knows what is really
there.


>- system specifications open for a distributed version where objects migrate
> or are copied on the fly from host to host to achieve best performance
> (but security required more than ever).
> If the language is truely high-level, this shouldn't affect it.
>

Security with Scheme over networks is easy, because it is a tree-language
(very easy to parse and analyze)--check with the Scheme Underground project
at MIT about this, they have mentioned using a Scheme-derivitive to transmit
software agents safely between non-trusting hosts to do things like search
remote data repositories.  They have an html page, but I don't have the URL.


>- Author authentification to retribute authors, or give them (dis)credit.
> It would be *very* useful if the language allowed arbitrary annotation of
> objects, which may mean things about object equality semantics (if
> association tables are to be built).
>
>- dynamic typing high-level (some may say "object-oriented") language as
> a standard interactive development tool -- no *need* for a shell and a
> bunch of stubborn languages that cope with each other's flaws. All systems
> specification are done in such a language. The language should have natural
> extensions that allow program specification and proof, and do secure
> type-checking.
>  That's the language I'm looking for.
>

Scheme... :)  I hope I'm not sounding like a broken record, but I think
Scheme is ideal for this sort of thing, and with static-typing extensions
(*concessions* if you ask me) it would allow very efficient compilation for
low-level system activities.  Scheme as it stands can compile to pretty
efficient code, but the dynamic type checking becomes extra baggage in
applications which don't need its expressive power.

I don't know what you mean by "secure typechecking."  To me security is
preventing programs from doing things that would be detrimental to the rest
of the system, while typechecking is done to prevent doing things that might
be detrimental to the program itself, i.e. would make it crash.

Each day I inch a little closer to deciding to design and implement a
Scheme-derivitive with support for concurrency, a robust module system
provided through slightly modified closures, and various additions to allow
the programmer to "sacrifice" constructs for extra speed; examples of
constructs to sacrifice would be continuations, mutution of bindings for
procedures, and even dynamic typing.  However, if I do this it will not be
soon enough to help you in your endeavor.  I still have many years of
schooling to do before I would inflict something like this on others.


>  I'm also considering joining Mike Prince's PIOS project, or the FIRE project.
>If there's another project (personal/university/commercial) that includes all
>(or a big part) of those features, please tell me. If you see any reason why
>it shouldn't be possible or wishable, or that it does not go for enough, or
>that it goes in the wrong direction, please tell me too. I *think* I am
>open-minded enough to hear it.
>

I think joining another project would be a good idea; just like languages,
the last thing we need is *another* new OS to fragment the communities.
Even Mach would be worth looking into--could your system be implemented on
top of Mach to use other Mach OSes concurrently?


karl c.

--
Karl Czajkowski
karlcz@uclink.berkeley.edu