-*- Text -*-
   This is the file .../MOOSE/info/Specs.nfo, which contains info
about the MOOSE Object & Stack Language.

File: Specs.nfo		Node: Top	Up:(MOOSE.nfo)

* Menu:

About the MOOSE:	MOOSE and other OSes.
* Intro::			General MOOSE Philosophy.
* Good or Wrong::		Good or Wrong ideas from other OSes.

Features:		MOOSE semantics.
* Objects::			A universal concept.
* Communications::		Interaction between objects.
* Persistence::			Objects live beyond external errors or
				rebooting.
* Version control::		Managing multiple versions of an object.

Standard Libraries:	see OSL and HLL Libraries, (* Libs::)

Standard Drivers.	Make objects from the external world.
* Memory::			Low-level memory interface.
* Time::			Essential to communication.

Languages:		Interface between the machine and the human being.
* OSL::				Low-level imperative language.
* HLL::				High-level relational language.

Low-level Interface to other computer systems:
* Communication protocols::	standard means to code objects, etc.

File: Specs.nfo, Node: Intro, Next: Good or Wrong, Prev: Top, Up: Top

   MOOSE was designed by expert programmers who wanted to implement all the
goodies ever invented for an OS and that have or not been invented yet, but
in a systematic manner: features added hither and lo on an old system just
make it more complicated to use and program.

   Let us first see the interesting features or flaws from existing systems,
before to decide an effective semantics to the system.

File: Specs.nfo, Node: Good or Wrong, Next: Objects, Prev: Intro, Up: Top

   OSes appeared together with the computer, even before the term appeared.
Whatever is looks like, the lowest level interface between the user programs
(if any) and the machine IS the OS; if no user program is possible, the we
have an embedded system, and the whole software is an OS.

   Since it was created in 1971, because its more or less free access by
computer scientists and evolved quickly with computer technology, Unix and
its clones constitute the standard model for OS: it integrates all the basic
concepts OSes need. These are: * a universal kind of object (the file),
* sharing of system resources including time (=multi-tasking), by multiple
programs owned each by a user among many (=multi-user). BUT, it inherits
catastrophical features from its history as a portable system on big machines:
* Files, system smallest objects are already big objects (come in 1 KB bunch
minimum); their semantics is VERY heavy, completely low-level, with no
objective, medium level convention about a file's type or use. Older versions
don't see processes as files (and processes are not persistent like files and
devices), and file semantics is so heavy it isn't interesting for most programs
to see processes as files as in newer versions. * Even processes are have a
very heavy completely low-level semantics; and the only standard way of
communication between processes is through the GLOBAL filesystem services, or
through completely local one-time, one-way ASCII only parameter mechanism (and
more recently through non-transmissible sockets). Of course, you could emulate
any kind of object sharing with this system, using global files as local ones,
with some authentification conventions; but doing so, you spend much of the
system resources because files are heavy, you lose all the hardly earned
system security, and you don't comply with traditional program calling
semantics. * The absence of any standard to code data, but ASCII imply a
very heavy and redundant use of long ASCII phrases in lieu of binary data
under unix, which slows program execution, eats memory and disk resources of
the system, and slow down considerably program writing by forcing programmers
to rewrite an interface between the command line and the program's internal
data each time they write a new program, which leads to long, globally
redundant, difficult to write, poorly interfaced programs. * The heaviness of
Unix make real-time application programming a real pain when it is made
possible by the sytem (which is nit sure); it is never 100% reliable.

   Systems like CP/M or its successor DOS were just minimal systems to fit in
then small machines. They are inspired by Unix, and inherit many of its flows
concerning files. ASCII is no longer a unique communication standard, but
this is because these OSes have hardware (DOS: chip-to-chip) compatibility
standards, which make program evolutivity and portability zero. They have
additional limitations (small filenames, no sharing of time or files, one
user). Such systems shouldn't seriously be though of as a model for anything
(but for themselves, and for emulators of their behavior).

   Newer systems often are nothing but a variant of Unix with some features or
conventions and new standard programs or libraries added on top of it; see
OS/2, Windows NT, etc. However, some systems bring original features: * amoeba
has distributedness, that is, the system do not manage just one computer, with
systems communicating with the others, but instead system objects (=files) are
shared between all the connected computers, which form a unique system. * NeXT
brings standard global object-orientation routines and calling convention; but
it still has much of Unix heaviness. * Chorus is much more object oriented,
and the upcoming version will be more than just a Unix box over an new kind of
kernel, but in the meantime, we have no solution.

   It is MOOSE's challenge to provide a true Object-Oriented operating system,
and not only an object-oriented layer above an existing operating system.

File: Specs.nfo,  Node: Objects, Prev: Good or Wrong, Next: Communications,	Up: Top

   MOOSE relies upon the concept of objects. But ``objects'' is a very
``a la mode'' word, and much hype have been said about it. So let's clarify
this term before continuing.

   In the MOOSE philosophy, an object is ANY abstraction you can represent on
the computer. Thus programming IS specifying objects and how they interact.
To the computer, anything is an object; if it is not an object, it doesn't
exist, for existing is being an object.

   Having said that, an operating system is something that provides a way for
objects to interact, to communicate, to live and die, to be easily specified
by the human user, etc.

   Here are the basics of MOOSE objects:
- Each object is identified uniquely by a key; the other objects that have the
key can use the object; those that don't can't.
- Each object can have one of these states: undefined, being computed,
computed.
- Each object's value can depend on many others, including time.
- Some objects are attributes or functions, and operate on some other objects.
An object that operates on another has a result which in turn is an object
(and can operate on other objects).

File: Specs.nfo, Node: Communications, Prev: Objects, Node: Stack primitives,		Next:Genericity, Up: Top


File: Specs.nfo, Node: Genericity, Next: Objects, Prev: Stack primitives, Up: Top

File: Specs.nfo, Node: Objects, Next: Implementation, Prev: Genericity,		Up: Top

File: Specs.nfo, Node: Implementation, Next: Unix externals, Prev: Objects,	Up: Top

File: Specs.nfo, Prev: Implementation, Node: Unix externals,			Next: DOS externals, Up: Top

File: Specs.nfo, Prev: Unix externals, Node: DOS externals,			Next: BIOS externals, Up: Top

File: Specs.nfo, Prev: DOS externals, Node: BIOS externals,			Next: MOOSE externals, Up: Top

File: Specs.nfo, Prev: BIOS externals, Node: MOOSE externals, Next: Top,	Up: Top

