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


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

* Menu:

About the OSL:
* Intro::			Why the OSL ?

Using the OSL:

Semantics:
* OSL principles::		OSL orientation.
* Objective primitives::	Objects as a universal concept.
* Dynamics::			Evolving objects.
* Parallelism::			Distributing objects.

Very High Level constructors:
* Recursion::			Self-definition.
* Constraints::			The way to a HLL.

High-Level constructors:
* Sets::
*  Set primitives::
*  Described sets::
*  Enumerated sets::
* Functions::
* Relations::
* Sequences::

Mid-level constructors:
* Set implementations::		Lists, Trees
* Functions::			Another universal concept.
*  Code::			The standard implementation scheme.
*  Table::			Ideal for functions with small starting set
*  Annotations::		Used for sparse functions
* Sequences::			A generic concept.
*  Stacks::			aka LIFO's.
*  Queues::			aka FIFO's.
*  Double Queues::		A complete scheme for sequential access.
* Trees::			A recursive structure.
*  B-Trees::			Binary trees.
*  AVL-Trees::			Some kind of balanced binary trees.

Low-level constructors:
* Raw Machine Code::		Raw machine code
* Tuples::			Product space.
* Pointers::			That says it.
* Arrays::			They have different levels of checking.
* Lists::			A raw list of objects.
* Raw Objects::			
* Linked Lists::		The same principle as in Lisp.
* Doubly Linked Lists::		Lists for bidirectional inspection.
* Pointed List::		List of consecutive variable length elements.
				with pointing table.

Very-Low level atoms:
* Atoms::			minimal understood things.


Standard types:
* Open Objects::		Standard interface to objects.
*  Dictionary::			Standard dictionary entry.
*  Attributes::			Standard Attribute managing.

Compiling:
* Compiling principles::	Transforming text into objects.
* Parsing::			Reading Text.
* Writing Code::		Writing executable code.

Generic Objective Libraries:
* Objects::			What are objects and their semantics.
* Implementation::		How are objects implemented for this nth time.

Other programming paradigms in OSL:
* Lazy evaluation::

Summary:
* OSL Words::			A summary of standard OSL words.
Summary:
* OSL Words::			A summary of standard OSL words.


**** OSL and the External World ****

Porting the OSL:
* Requirements::		What systems to port the OSL to.
* Implementation techniques::	Various ways to implement objects.
*  
*  

System Externals:
* System Files::		Externals to access files.
* Unix externals::		Particularization to Unix, and other Unix IO.
* DOS externals::		Simulating Unix under DOS, plus other DOS IO.
* BIOS externals::		Accessing the Hardware using the BIOS.
* PC externals::		Externals for direct hardware IO on PCs.

Interfacing with other languages:
* Links:(Links.nfo).		The Links set of library for linking OSL and
				external languages.

File: OSL.nfo, Node: Intro, Next: Porting the OSL, Prev: Top, Up: Top

   OSL was originally conceived both as a stack- and object- oriented language
for the quickest interactivity as well as the best code genericity.

   It provides an abstract imperative language for the MOOSE project, as an
intermediate between the HLL (High-Level Language) and the machines. Actually,
OSL can be viewed as a restriction of HLL, or HLL as an extension to OSL. OSL
is used as HLL's (and thus OSL's own) preprocessor and target language. OSL is
meant to be extensible and adaptable to any particular purpose.

   In particular, an OSL command line might be an efficient shell; the OSL can
be an efficient target language for compilers; it can be an efficient macro
language for preprocessing, scripting and the like.

File: OSL.nfo, Node: Porting OSL, Next: OSL Principles, Prev: Intro, Up: Top

   The current OSL implementation as a language should not be difficult to
port to any system with 20 bit or wider words.

   But the environment and library should be much more difficult to port
efficiently to another system. Well, it's feasible, but I wish you good
luck.

   The main problems will be threading and event programming: OSL provides
a great number of independent lightweight objects that interact in many
discrete ways, whereas existing OSes are very bulky and don't like small
things; moreover, those systems seldom provide usable real-time objects,
interobject communication, 

File: OSL.nfo, Node: OSL principles, Next: Objective primitives,		Prev: Porting the OSL, Up: Top

   The OSL is an object oriented language, which means that it believes in a
both unified and modular view of programming (see * Genericity:: or
* Object::).

   The basic OSL constructor is the (single-user) Stack.
   Actually for each defined and opened object type, an implicit stack is
created to manipulate such objects. Of course, code compiled from OSL need not
implement these straightforwardly, and it is a good idea to merge (locally or
globally) stacks when possible.

   And note that in particular, there is an Int stack for system integers
(that are assumed to be larger than pointers, so that then can code size of
in-memory objects). And a Code stack for OSL instructions. If one restricts
to those two types, one obtains a classical FORTH implementation. But if one
uses other types, one have something more like smalltalk or a high-level
OO language.

File: OSL.nfo, Prev: OSL principles, Node: Objective primitives,		Next: Stack primitives, Up: Top

  Here is the grammar of definition syntax:
     Define /INTRODUCTORY WORDS/ /NAME/ /DEFINITION/ /./
    where
     /INTRODUCTORY WORDS/ can be
     /NAME/			is an name object.
     /DEFINITION/ is an optional rightwise boolean operator to be
		interpreted as a constraint for the object, with as
		being overloaded to =
		
     /./ is an optional isolated full stop.
   example:
     Define the number «n» : n=2*n-1 .
     Define «Coordinates» as Int*Int .


File: OSL.nfo, Prev: Objective primitives, Node: Stack primitives,		Next: Parsing principles, Up: Top


File: OSL.nfo, Prev: Stack primitives, Node: Parsing principles,		Next: Naming, Up: Top

   Now, you wonder, splendid objects you described to me, but how do I
tell the computer which object to use ? That is, OSL is an object system
rather than a language. It was explained how computer objects interacted
the one wih the ohers, but how can the human interact with the computer ?

   The answer is that there is not a one priviledged method to access
objects. The standard OSL Library includes stream objects, objects
to transform streams into objects, objects to see code being produced as
streams, and objects to output code to these streams. No one is forced
to use any of these, although the use of standard calls to output effective
calls seems necessary to maintain some portability.

   See the * parser-kernel::
   and see * streams::

File: OSL.nfo, Prev: Parsing principles, Node: Naming, Next: Constructing,	Up: Top

Parsing:

* Naming::			How to name an object.
* Constructing::		Constructing objects.
* Modifying the grammar::	How to modify the thing.


File: OSL.nfo, Prev: Naming, Node: Constructing, Next: Modifying the grammar,	Up: Top

   Each object will ultimately given a name to access it, whether this name be
secret or not to the user. To a given user, an object appears if and only if he
knows its name. T


File: OSL.nfo, Prev: Constructing, Node: Modifying the grammar,			Next:Genericity, Up: Top


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


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


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


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

File: OSL.nfo, Node: OSL Words, Prev: ,Next: Up, Up: Top

File: OSL.nfo, Node: OSL Words, Prev: ,Next: , Up: Top
