Use git submodule instead of wiki's copy

.gitmodules

@@ -0,0 +1,3 @@
+[submodule "doc/wiki"]
+	path = doc/wiki
+	url = https://github.com/vladfolts/oberonjs.wiki.git

doc/wiki

@@ -0,0 +1 @@
+Subproject commit af98fc7ccb40c16b19682776bd3c1ee6f6b81d40

doc/wiki/JS-module.md

@@ -1,30 +0,0 @@
-*JS* is a built-in pseudo module. It serves as a bridge to JavaScript world from oberon program. The major purpose of this module is to make possible to write bindings to JavaScript libraries.
-
-    MODULE test;
-    IMPORT JS;
-    BEGIN
-        JS.alert("Hello, World!")
-    END test.
-
-You can call any JavaScript function (from global scope) using notation "JS.anyName" and pass any number of any arguments to it. Compiler will not check anything - these are JavaScript rules, all type errors will be raised in runtime.
-
-### JS.do
-
-*JS.do* is a predefined procedure to place specified JavaScript code directly to compiler output.
-
-    JS.do("throw new Error('test')");
-
-### JS.var
-
-*JS.var* is a type intended for explicit declaration of variables specific for JavaScript code.
-
-    VAR v: JS.var;
-    ...
-    v := JS.someFunction();
-
-*JS.var* is considered compatibale with any other type (there no any type checking as for JavaScript variables). But the opposite is not true: you cannot you cannot assign *JS.var* to Oberon types:
-
-    VAR v: JS.var; i: INTEGER;
-    ...
-    v := i; (* OK *)
-    i := v; (* compile error *)

doc/wiki/Original-report-refinements.md

@@ -1,114 +0,0 @@
-Here are implemented refinements to the original language report (see doc/Oberon07.Report.pdf). 
-* These refinements do not contradict to the original report.
-* These refinements are not extensions of the original report because they do not extend syntax or language semantics.
-* These refinements are not directly inherited from original report using "common sense".
-
-However these refinements are crucial from programming techniques standpoint so they are worth to be documented explicitly.
-
-1. Support opaque data types.
------------------------------
-
-Consider you want to encapsulate some data structure inner details. But you need this data to be passed to/from the module. You can do it in this manner:
-
-    MODULE impl;
-
-    TYPE T* = RECORD hiddenField: INTEGER END;
-
-    PROCEDURE do(t: T);
-    (* t.hiddenField can be accessed only in this module *)
-    END do;
-
-    END impl.
-
-This example works just fine until you need some specific initialization for 'hiddenField'. And only module 'impl' knows how to initialize T in the right way. We can export special procedure for initialization:
-
-    PROCEDURE init*(VAR t: T);
-    BEGIN
-        t.hiddenField := 123;
-    END init;
-
-All other modules have to call impl.init(t) every time they need to initialize T. But this requirement can be easily ignored leading to some run-time errors.
-
-To resolve this problem we can export only pointer type and **forbid creation (NEW) for non-exported RECORD types**.
-Full example:
-
-    MODULE impl;
-
-    TYPE T* = POINTER TO RECORD hiddenField: INTEGER END;
-
-    PROCEDURE init*(): T;
-    VAR result: T;
-    BEGIN
-    	NEW(result);
-        result.hiddenField := 123;
-    	RETURN result
-    END init;
-
-    PROCEDURE do*(t: T);
-    (* t.hiddenField can be accessed only in this module *)
-    END do;
-
-    END impl.
-
-    MODULE test;
-    IMPORT impl;
-    VAR p: impl.T;
-    BEGIN
-    	(* NEW(p) will produce complier error *)
-    	p := impl.init();
-    	impl.do(p);
-    END test.
-
-2. Variables default values
----------------------------
-All variables have zero as a default value (before first assignment). For pointer/procedure types it is NIL. For sets - empty set. For STRING - empty string.
-
-    MODULE m;
-    VAR r: RECORD field: INTEGER END;
-    BEGIN
-        ASSERT(r.field = 0);
-    END m.
-
-3. CASE with type guards
-------------------------
-CASE with type guard has notorious loophole allowing to violate type system. Consider following example:
-
-    MODULE test;
-    TYPE
-        Base = RECORD END; 
-        Derived1 = POINTER TO RECORD(Base) derived1Field: INTEGER END;
-        Derived2 = POINTER TO RECORD(Base) END;
-    VAR p: POINTER TO Base; p1: Derived1; p2: Derived2;
-
-    PROCEDURE assignToDerived2();
-    BEGIN
-        NEW(p2);
-        p := p2;
-    END assignToDerived2;
-
-    PROCEDURE check();
-    BEGIN
-        CASE p OF
-            Derived1: 
-                assignToDerived2(); (* p is not Derived1 anymore *)
-                p.derived1Field := 123; (* type system violation *)
-        END;
-    END check;
-
-    BEGIN
-        NEW(p1);
-        p := p1;
-        check();
-    END test.
-
-Oberonjs does not change the type of pointer passed as VAR argument in CASE to reduce most unexpected bugs (referenced pointer can be changed indirectly):
-
-    PROCEDURE check(VAR p: PBase);
-    BEGIN
-        CASE p OF
-            Derived1: 
-                (* this code is compiled successfully but 'p' has type PBase here, not Derived1 *)
-        END;
-    END check;
-
-I would recommend to use Eberon's [[implicit type narrowing|Eberon-implicit-type-narrowing]] instead of CASE with type guards - it is as efficient as CASE but does not have described problem. 

doc/wiki/compiler-options.md

@@ -1,12 +0,0 @@
-*checkIndexes* option generates additional code to check ARRAY or STRING indexes at run-time.
-
-Example:
-
-    var language = require("oberon/oberon_grammar.js").language;
-    var options = {checkIndexes: true};
-    result = require("oc.js").compile(
-            source_code, 
-            language, 
-            errors_handler,
-            options
-            );

doc/wiki/eberon-FOR..IN.md

@@ -1,34 +0,0 @@
-*FOR..IN* loop statement is used to iteratate through arrays, [[STRING|eberon-strings]]s and [[MAP|eberon-associative-arrays]]s. For arrays and strings all elements are iterated from the beginning to the end.
-
-### Syntax
-
-    FOR [key,] value IN array DO
-        ...
-    END;
-
-_key_ is an optional variable standing for array/string's index (from 0 to LEN(_array_) - 1) or MAP's key. _key_ type is INTEGER for arrays and strings and [[STRING|eberon-strings]] for [[MAP|eberon-associative-arrays]]s.
-_value_ is a variable standing for element's value.
-These variables have no a separate declaration and their visibility scope is inside loop only. Also these variables are read-only - similar to non-VAR parameters.
-
-### Example
-
-    VAR
-        a: ARRAY 3 OF BOOLEAN;
-    BEGIN
-        FOR i, v IN a DO
-            ASSERT(a[i] = v);
-        END;
-
-        (* not using key here *)
-        FOR v IN a DO
-        END;
-    END;
-
-    VAR
-        m: MAP OF INTEGER;
-    BEGIN
-        FOR k, v IN m DO
-            ASSERT(v = 0);
-            ASSERT(k # "");
-        END;
-    END;

doc/wiki/eberon-array-initializers.md

@@ -1,26 +0,0 @@
-Array initializers create array with specified elements as a shortcut instead of declaring array variable and initialize each element separately.
-
-### Syntax
-
-	"[" expression {, expression} "]"
-
-### Example
-
-	
-	MODULE test;
-	CONST a = [1, 2, 3];
-
-	PROCEDURE passArray(a: ARRAY OF INTEGER);
-	END;
-
-	BEGIN
-		passArray(a);
-		passArray([123, 456]);
-	END test.
-
-### Semantics
-
-* all expressions used in initializers list must have the same type
-* if string literal is used as expression then element's type is [[STRING|eberon-strings]]
-* array initializers can be used to define a constant in CONST section
-* array initializers can be used wherever constant expression of corresponded array's type can be used 

doc/wiki/eberon-array-methods.md

@@ -1,17 +0,0 @@
-*indexOf* method is applied to array to search for specified element:
-
-    elementIndex := array.indexOf(elementValueToSearch);
-
-*indexOf* returns the index of the first element of array which value is equal to the value specified as the first argument. Its logic is equivalent to the following code:
-
-    elementIndex := 0;
-    WHILE (elementIndex < LEN(array)) & (array[elementIndex] # elementValueToSearch) DO
-        INC(elementIndex)
-    END;
-    IF elementIndex = LEN(array) THEN
-        elementIndex := -1
-    END;
-
-That is a lot of code and it cannot be reused in a library (element type can vary). On the other side this operation is used pretty often so it was implemented as [[Eberon|eberon]] extension.
-
-*indexOf* can be applied only if elements type can be used in relation operation, i.e. it cannot be applied to array of records or array of arrays.

doc/wiki/eberon-associative-arrays.md

@@ -1,30 +0,0 @@
-Associative arrays are indexed by string keys. The basic operations on a such array is storing a value (having declared type) and extracting the value given the key (string).
-
-### Syntax
-Associative arrays are declared using keyword *MAP*:
-    
-    VAR m: MAP OF INTEGER; (* m is associative array storing integer values *)
-
-    TYPE T = RECORD field: MAP OF T END; (* associative array can have records as values *)
-
-### Semantics
-Notation similar to ordinary arrays is used to acceess, add a new element or replace existing element (with the same key) in associative array:
-    
-    m[key] := value; (* add/replace element *)
-    value := m[key]; (* get element *)
-
-_key_ type should be compatible with [[STRING|eberon-strings]] and _value_ should be compatible with declared type. Attempt to access element with non-existing key will break program execution.
-
-Keyword *IN* is used to test whether element with specified key is present in the array:
-    
-    IF key IN m THEN
-
-It is also possible to iterate through associative array keys/values using [[FOR..IN|eberon-FOR..IN]] loop.
-    
-To remove element from array *remove* method is used:
-    
-    m.remove(key)
-
-To remove all elements from array *clear* method is used:    
-
-    m.clear()

doc/wiki/eberon-dynamic-arrays.md

@@ -1,57 +0,0 @@
-Dynamic arrays are similar to static arrays but their length can be changed at runtime - new elements can be added or removed.
-
-### Syntax
-Dynamic arrays are declared in the same way as static arrays - 'dynamic' dimension is marked with '*':
-    
-    a1: ARRAY * OF INTEGER;
-    a2: ARRAY *, * OF BOOLEAN;
-    a3: ARRAY *, 10, * OF CHAR;
-
-### Semantics
-Initial length of dynamic array is 0.
-To add a new element *add* method is used:
-
-    array.add(value);
-
-Added _value_ type should be compatible with the array elements type. 
-To remove element from array *remove* method is used:
-
-    array.remove(index);
-
-INTEGER _index_ specifies element index to remove.
-Method *clear* is used to remove all elements from array:
-
-    array.clear();
-
-Dynamic arrays also have [[indexOf|eberon-array-methods]] method (similar to static arrays).
-
-* Dynamic array can be passed as open array to procedure.
-* Procedure can have dynamic array as VAR parameter and change content of passed array. But dynamic array cannot be passed as non-VAR paramater - ordinary open array should be used.
-* Procedure can have dynamic array as a result - in this case a copy of array is returned.
-
-Example:
-
-    MODULE Test;
-    TYPE
-        A = ARRAY * OF INTEGER;
-    VAR
-        a1, a2: A;
-    
-    PROCEDURE returnDynamicArray(VAR a: A): A;
-        RETURN a
-    END returnDynamicArray;
-
-    BEGIN
-        a1.add(3);
-        a2 := returnDynamicArray(a1);
-        ASSERT(LEN(a2) = 1);
-        ASSERT(a2[0] = 3);
-
-        a1[0] := 5;
-        ASSERT(a2[0] = 3); (*array was copied, a1 and a2 do not share elements*)
-    END Test.
-
-* Dynamic array can be assigned to another dynamic array - destination array content is replaced by the content of source array, lenght became the same as the length of source array.
-* Dynamic array can be assigned to open or static array but not vice versa.
-* Element types should be compatible for all array assignment operations.
-* Dynamic array cannot be assigned to NIL.

doc/wiki/eberon-implicit-type-narrowing.md

@@ -1,33 +0,0 @@
-Original Oberon-07 CASE with type guards has [[notorious loophole|Original-report-refinements#3-case-with-type-guards]]. *Implicit type narrowing* is introduced as alternative solution without possible type violation problem.
-
-The idea of *implicit type narrowing* is to make the compiler smart enough to comprehend that type testing (using IS) and following IF branch or logical conjunction (&) in expression narrows just tested variable type. The same type narrowing happens in the inverse case: logical not (~) for IS operation and following ELSE branch or logical disjunction (OR). Also compiler should guarantee that tested variable is not modified after type narrowing so there is no loopholes to corrupt type system by chance. That guarantee is easy to reach in case of [[In Place Variables|eberon-in-place-variables]] because their scope is very local and they cannot be modified by local procedures. Type narrowing is also appling to procedure arguments because they [[cannot be modified|Eberon-non-VAR-arguments-are-read-only]]. So if the example will use *pb* variable as *in place* variable then it will be compiled without addition type casts:
-
-    VAR
-        pbVar: PBase;
-    BEGIN
-        pb <- pbVar;
-        IF pb IS PDerived THEN
-            pb.derivedField := 123;
-        END;
-
-        ASSERT(~(pb IS PDerived) OR (pb.derivedField = 123));
-    END.
-
-Type narrowing is also applies to [[Ternary operator|eberon-ternary-operator]], WHILE statement and its ELSIF branches.
-
-### Generic Message Bus
-*Implicit type narrowing* is also used for VAR arguments to support generic message bus pattern.
-
-    TYPE
-        Message = RECORD END;
-        Derived1 = RECORD (Message) derivedField1: BOOLEAN END;
-        Derived2 = RECORD (Message) derivedField2: BOOLEAN END;
-
-    PROCEDURE handleMessage(VAR msg: Message);
-    BEGIN
-        IF msg IS Derived1 THEN
-            ASSERT(msg.derivedField1);
-        ELSIF msg IS Derived2 THEN
-            ASSERT(msg.derivedField2);
-        END;
-    END handleMessage;        

doc/wiki/eberon-in-place-variables.md

@@ -1,53 +0,0 @@
-*In place* variables are introduced to relieve VAR section from variables which have very local scope or temporary nature. *In place* variable is declared and initialized in the same place where it is needed so there is no gap between its declaration and usage.
-
-### Syntax
-*In place* variable can be declared wherever the grammar *statement* is suitable:
-
-    InPlaceStatement = ident "<-" expression
-
-Example:
-
-    i <- 123;
-
-*In place* variable is declared and assigned in the same time. The type of variable is not specified but deduced from the expression on the right. In the example above variable will have type INTEGER. If expression is a string literal then deduced type is [[STRING|eberon-strings]]. In the following example the variable will have the same type as a result of PROCEDURE f:
-
-    x <- f();
-
-Although the type is not specified explicitly a variable is still statically typed (its type cannot be changed) with deduced type in the same way as a regular variable (declared in VAR section).
-
-*In place* variable behaves in the same way as a regular variable (declared in VAR section). It can be reassigned or passed as a VAR parameter to procedure. When variable is initialized with a record type - it will be copied as if variable of this record type was declared in VAR section and then assigned to another variable of record type. When variable is initialized with an array type - array will be copied. *In place* variable cannot be initialized with open array because its full type (including size) is unknown.
-
-    PROCEDURE p(a1: SomeRecord; VAR a2: SomeRecord);
-    BEGIN
-        v1 <- a1; (* a1 will be copied to v1 *)
-        v2 <- a2; (* a2 will be copied to v2 *)
-    END p;
-
-Please notice that *v1* and *v2* will be copies (modifiable) of variables of type SomeRecord even if some descendants of type SomeRecord were passed to the procedure *p* as actual parameters.
-
-*In place* variable can be used as FOR variable:
-
-    FOR i <- 0 TO 10 DO 
-    ...
-    END
-
-### Scope rules
-
-*In place* variable is visible from the place of declaration textually down to the end of procedure or outer IF/WHILE/FOR's END or ELSE/ELSIF/CASE branch.
-
-*In place* variable name cannot duplicate any other variable name from outer scopes up to procedure scope.
-
-    PROCEDURE p();
-    VAR v1: INTEGER;
-    BEGIN
-        v1 <- 1; (* compile error: 'v1' already declared in procedure scope *)
-        v2 <- 2; (* OK *)
-        IF expression THEN
-            v2 <- 2; (* compile error: 'v2' already declared in procedure scope *)
-            v3 <- 3; (* OK *)
-        ELSE
-            v3 <- 3; (* OK, another v3 is declared in separate scope *)
-        END;
-
-        v3 := 3; (* compile error: undeclared identifier: 'v3')
-    END p;

doc/wiki/eberon-methods.md

@@ -1,70 +0,0 @@
-Methods are introduced to support OOP polymorphism for a data type (RECORD in case of oberon). Wirth suggests to achieve such polymorphism using procedure fields. This approach is not reliable nor efficient, also it produces a lot of garbage code. So Eberon supports methods natively.
-
-### Syntax
-Methods are declared similary to record fields. Original oberon record declaration modified to:
-
-    RecordType = RECORD ["(" BaseType ")"] [FieldListSequence] END.
-    FieldListSequence = FieldList {";" FieldList}.
-    FieldList = MethodHeading | (IdentList ":" type).
-
-*MethodHeading* is a new syntax for methods declaration:
-
-    MethodHeading = PROCEDURE identdef [formalParameters].
-
-Example:
-
-    Figure = RECORD
-        PROCEDURE draw(color: INTEGER)
-    END;
-
-Declared methods may be defined later using the same syntax as for ordinary procedures but having type name as a prefix to method name:
-
-    ProcedureDeclaration = ProcedureHeading ";" ProcedureBody [ident ["." ident]].
-    ProcedureHeading = PROCEDURE [ident "."] identdef [FormalParameters].
-
-Example:
-
-    PROCEDURE Figure.draw(color: INTEGER);
-    END Figure.draw;
-
-New keywords **SELF** and **SUPER** were introduced to reference record instance in method definition and to call base type method.
-
-Example:
-
-    Triangle = RECORD(Figure)
-        border: BOOLEAN
-    END;
-
-    PROCEDURE Triangle.draw(color: INTEGER);
-    BEGIN
-        SUPER(color);
-
-        IF SELF.border THEN
-            drawTriangleBorder(SELF);
-        END;
-    END Triangle.draw;
-
- **SELF** acts as a variable of record instance. If pointer to type is needed then a special syntax can be used to reference a pointer to record instance: **SELF(POINTER)**. The compiler check if **SELF(POINTER)** was used in record methods and forbids to declare variables of such types - only pointer (created with NEW) can be declared.
-
-Example:
-
-    TYPE 
-        T = RECORD PROCEDURE method() END;
-        PT = POINTER TO T;
-        VAR pVar: PT;
-
-    PROCEDURE T.method(); 
-    BEGIN 
-        pVar := SELF(POINTER);
-    END T.method;
-
-### Semantics
-Methods semantics basically the same as in popular OOP languages (Java, C#, C++).
-
-Each particular method is declared once (in RECORD declaration). Method declaration with the same name is not allowed in type extensions. Type extensions then can define this method in the way specific for a particular extension type. Method definition should:
-* have the same signature as a method declaration
-* be placed in the same scope (module or procedure) as the extension type declaration
-
-Method definition may be missed for a particular type. In this case the type is *abstract*. Abstract type cannot be *instantiated* - variable of this type cannot be declared or pointer to this type allocated using NEW. Method should be defined at least once in inheritance chain for a type to be non-abstract.
-
-SUPER cannot be used to call an abstract method.

doc/wiki/eberon-non-VAR-arguments-are-read-only.md

@@ -1,2 +0,0 @@
-Original Oberon-O7 allows to change procedure arguments (to use them as ordinary variables) unless they are non-VAR ARRAY or RECORD. Eberon makes this rule more consistent - all non-VAR arguments are read-only.
-This restriction is introduced in the first place to support [[implicit type narrowing|eberon-implicit-type-narrowing]] for POINTER arguments. But anyway reusing arguments as variables I personally consider as a bad practice because their scope is a whole procedure and possibility of modifing requires more attention while reading.

doc/wiki/eberon-operator-NEW.md

@@ -1,31 +0,0 @@
-Original procedure NEW in Oberon is not always convenient to use - it requires already declared pointer variable:
-
-    PROCEDURE make(): Pointer;
-    VAR
-        result: Pointer;
-    BEGIN
-        NEW(result);
-        RETURN result;
-    END;
-
-Operator NEW in [[Eberon|eberon]] returns a pointer to created record. So code above could be rewritten in shorter form like:
-
-    PROCEDURE make(): Pointer;
-        RETURN NEW T();
-    END;
-
-Also operator NEW can be used to initialize a pointer variable to base record (while creating derived record):
-
-    IF condition1 THEN
-        base := NEW Derived1();
-    ELSE
-        base := NEW Derived2();
-    END;
-
-Operator NEW also can be used to create a record having constructor with parameters:
-
-    r := NEW T(param1, param2);
-
-Operator NEW from language grammar standpoint is a part of *designator* so it is possible to denote record fields right after creating:
-
-    NEW T().field

doc/wiki/eberon-procedure-call-result.md

@@ -1,33 +0,0 @@
-Original oberon does not allow to denote procedure call result if it returns pointer to record or procedure type. This restriction requires additional temporary variables and redundant code without visible profit. So **Eberon** gets rid of this restriction by changing original oberon grammar for _selector_.
-
-### Syntax
-    selector = "." ident | "[" ExpList "]" | "^" | "(" qualident ")" | ActualParameters.
-
-Example:
-
-    MODULE Test;
-    TYPE 
-        Proc = PROCEDURE;
-        T = POINTER TO RECORD
-            i: INTEGER
-        END;
-
-    PROCEDURE proc();
-    END proc;
-
-    PROCEDURE getProc(): Proc;
-        RETURN proc
-    END getProc;
-
-    PROCEDURE getRecord(): T;
-    VAR
-        result: T;
-    BEGIN
-        NEW(result);
-        RETURN result
-    END getRecord;
-
-    BEGIN
-        getProc()(); (* OK in Eberon, error in original oberon *)
-        getRecord().i := 123; (* OK in Eberon, error in original oberon *)
-    END Test.

doc/wiki/eberon-record-constructor.md

@@ -1,155 +0,0 @@
-**Record Constructor** is a procedure associated with a record and invoked every time when an instance of record is instantiated. Being invoked automatically constructor is a unified way to initialize record and maintain record's invariant.
-
-### Declaration
-Constructor is declared as a record [[method|eberon-methods]] with the same name as the record type name:
-
-    T = RECORD
-        PROCEDURE T(); (* this is constructor declaration for record 'T' *)
-    END;
-
-    PROCEDURE T.T();
-    (* this is constructor definition *)
-    END;
-
-Constructor cannot have result type specified.
-
-### Parameters
-Constructor can have parameters:
-
-    T = RECORD
-        PROCEDURE T(param1: INTEGER, param2: BOOLEAN);
-    END;
-
-Records having constructor with parameters cannot be declared in VAR section or pointers to such records cannot be passed to *procedure NEW*. [[In place variables|eberon-in-place-variables]] or [[operator NEW|eberon-operator-NEW]] must be used instead. Also such records cannot be used as elements of static arrays - use [[dynamic arrays|eberon-dynamic-arrays]] instead.
-
-### Call constructor as an expression
-Constructor can be called as an ordinary procedure by its name. Call result type is the type of constructed record:
-
-    record <- T(123, TRUE); (* initialize in place variable 'record' with instance of 'T' *)
-
-    NEW T(123, TRUE); (* construct pointer to 'T' using operator NEW *)
-
-    do(T()); (* pass instance of 'T' to procedure 'do' *)
-
-    T().field; (* construct instance of record 'T' and designate its field 'field' *)
-
-### Type extension
-Constructor parameters are inherited from base type to derived:
-
-    Base = RECORD
-        PROCEDURE Base(param: INTEGER);
-    END;
-
-    Derived = RECORD(Base)
-    END;
-
-Here constructor was not declared for 'Derived' but it was inherited from 'Base' so 'Derived' now can be constructed only using the same parameters as for constructing 'Base':
-
-    Derived(123);
-
-### Initialization list
-Special syntax is introduced to call base constructor and to initialize fields having their own parameterized constructors:
-
-    InitList = "|" ("SUPER" ActualParameters fields) | (InitField fields))
-    fields = {"," InitField}
-    InitField = ident ActualParameters
-
-Consider following example:
-
-    Base = RECORD
-        PROCEDURE Base(param: INTEGER);
-    END;
-
-    Derived = RECORD(Base)
-        PROCEDURE Derived();
-    END;
-
-Constructor 'Derived' has no parameters and 'Base' does have. To pass actual parameters to base constructor *SUPER* is used in initialization list:
-
-    PROCEDURE Derived.Derived() | SUPER(123); (* call base constructor with parameter '123' *)
-    END;
-
-Similar thing is for fields having parameterized constructors:
-
-    Field = RECORD 
-        PROCEDURE Field(a: INTEGER);
-    END;
-
-    T = RECORD
-        PROCEDURE T();
-
-        f: Field;
-    END;
-              
-    PROCEDURE T.T() | f(123); (* pass '123' to constructor of record's field 'f' *)
-    END;
-
-Fields of non-record types also can be referenced in initialization list. In this case field will be assigned to single actual parameter:
-
-    T = RECORD
-        PROCEDURE T();
-
-        f1: INTEGER;
-        f2: BOOLEAN;
-    END;
-              
-    PROCEDURE T.T() | f1(123), f2(TRUE);
-    END;
-
-Fields must be referenced in the initialization list in the same order as they declared in record. For example above "f2(TRUE), f1(123)" will cause compiler error.
-Only record's own fields can be referenced (not fields from base record). Fields of non-record types may be missed in the list - in this case they will be initialized using default values. Record fields having constructor without parameters will be initialized automatically and must be not referenced in initialization list. All fields are initialized strictly in the same order as they declared in record - no matter if they referenced in the initialization list or initialized automatically. It is possible to use *SELF* in initialization list but be aware of the initialization order - do not use *SELF* to access not initialized field (the compiler does not diagnose that).
-
-The order of execution in constructor: 
-* call base constructor (if present), using *SUPER* (with parameters) or automatically (no parameters)
-* initialize fields strictly in order from record declaration (mixing default values or supplied parameters in the initialization list)
-* execute constructor body (BEGIN/END section)
-
-Example:
-
-    Base = RECORD
-        PROCEDURE Base(param: INTEGER);
-    END;
-
-    Field1 = RECORD 
-        PROCEDURE Field1(a: INTEGER);
-    END;
-
-    Field2 = RECORD 
-        PROCEDURE Field2();
-    END;
-
-    Field3 = RECORD 
-    END;
-
-    T = RECORD
-        int: INTEGER;
-        field1: Field1;
-        field2: Field2;
-        field3: Field3;
-        bool: BOOLEAN;
-        set: SET;
-    END;
-
-    PROCEDURE T.T() | SUPER(123), field1(SELF.int), bool(TRUE);
-    BEGIN
-        ASSERT(SELF.bool);
-    END;
-
-Execution order for example above will be:
-* call Base(123) 
-* initialize field 'int' with default value '0' - automatically
-* initialize field 'field1' by calling Field1(SELF.int)
-* initialize field 'field2' by calling Field2() - automatically
-* initialize field 'field3' (without constructor) - automatically
-* initialize field 'bool' with TRUE
-* initialize field 'set' with default value '{}' - automatically
-
-### Export
-Constructor can be exported using '*' notation
-
-    T* = RECORD
-        PROCEDURE T*();
-    END;
-
-If constructor is exported then the record itself must be exported too.
-If constructor is not exported then record cannot be instantiated or extended in other modules.

doc/wiki/eberon-record-fields-read-only-export.md

@@ -1,32 +0,0 @@
-Read-only export is introduced for record fields using '-' mark - in the same way as it is done in Component Pascal.
-The major reason for this extension is to maintain data integrity without obligation to write down corresponfing procedures-accessors. I.e. instead of hiding (not exporting) record field and giving procedure-accessor (exported) for reading field value it is possble to just mark a field as exported for reading only.
-
-### Syntax
-    identdef = ident ["*" | "-"].
-
-Example:
-
-    MODULE m1;
-    TYPE 
-        T* = RECORD
-            i-: INTEGER
-        END;
-        TP* = POINTER TO T;
-
-        PROCEDURE make*(): TP;
-        VAR result: TP;
-        BEGIN
-            NEW(result);
-            result.i := 123; (* field 'T.i' can be modified in this module *)
-            RETURN result
-        END make;
-    END m1.    
-
-    MODULE m2;
-    IMPORT m1;
-    VAR p: m1.TP; 
-    BEGIN
-        p := m1.make();
-        ASSERT(p.i = 123); (* field 'T.i' can be accessed in this module *) 
-        p.i := 321; (* compiller error, 'T.i' cannot be modified in this module *)
-    END m2.        

doc/wiki/eberon-strings.md

@@ -1,28 +0,0 @@
-A new basic type STRING is introduced because oberon has nothing to deal with strings of arbitrary length. Any possible library solution will have a lot of syntax noise and have no chance to optimize trivial string operations. Oberon is not C++ with all these complex things (like operator overloading etc.) which make library solution viable so it is simplier to just support a new basic type on compiler level.
-
-### Semantics
-STRING is a basic type. It represents a sequence of characters of any length (including zero - empty string).
-STRING is very similar to ARRAY OF CHAR:
-* STRING can be indexed [] as CHAR
-* predefined procedure LEN returns the length of STRING
-* STRING can be compared
-* STRING can be assigned from string literal
-* STRING can be passed as open non-VAR ARRAY OF CHAR
-
-But also there are differences:
-* STRING content is read-only, it never modified
-* ARRAY OF CHAR cannot be assigned to STRING or passed as STRING
-* STRING can be returned as a result of procedure
-
-STRING supports concatenation through '+' operator. Also '+' is supported for string literals:
-
-Example:
-
-    CONST constString = 22X + "abc" + 22X;
-    VAR s: STRING;
-    ...
-    s := s + constString + s;
-
-STRING [default value](/vladfolts/oberonjs/wiki/Original-report-refinements#2-variables-default-values) is empty string - "". STRING cannot be NIL.
-
-All special cases described in original Wirth report regarding to ARRAY OF CHAR (comparing to other array types) seem not actual after introducing a separate type STRING to support strings but they are left as is in [Eberon](/vladfolts/oberonjs/wiki/eberon) to maintain compatibility with original oberon.

doc/wiki/eberon-syntax-relaxations.md

@@ -1,29 +0,0 @@
-Here are additions to orginal oberon grammar to make it less strict in some cases.
-
-### Optional procedure identifier at the end
-Example:
-
-    PROCEDURE p; END; (* 'p' is note required before 'END' *)
-
-Pocedure name duplicating at the end is useless in case of small procedures. So it is optional in [[Eberon|eberon]].
-
-### Extra semicolon can be used in record last field declaration
-Example:
-
-    TYPE 
-        T = RECORD 
-            field1: INTEGER; 
-            field2: INTEGER; 
-            fieldn: INTEGER; (* semocolon is allowed here in Eberon, prohibited by original oberon grammar *)
-        END;
-
-Although this semicolon is "extra" from grammar standpoint it just inconvenient from editing/merge standpoint. So [[Eberon|eberon]] allows to have it.
-
-### Extra semicolon can be used after RETURN
-Example:
-    
-    PROCEDURE p(): INTEGER; 
-        RETURN 0; (* semocolon is allowed here in Eberon, prohibited by original oberon grammar *)
-    END;
-
-Although RETURN is not a statement from oberon grammar standpoint (it is a part of procedure declaration) it still looks and feels like a statement. So [[Eberon|eberon]] allows to have extra semicolon after it.

doc/wiki/eberon-ternary-operator.md

@@ -1,41 +0,0 @@
-Ternary operator can be used as a shortcut for the IF/ELSE statement.
-
-### Syntax
-
-	condition ? a : b
-
-_condition_ is a boolean expression.  
-_a_ and _b_ are expressions to evaluate.  
-The operator returns _a_ when condition is TRUE and _b_ when condition is FALSE. Ternary operator has lowest priority.
-
-### Example
-
-	PROCEDURE max(a, b: INTEGER): INTEGER;
-	VAR
-		result: INTEGER;
-	BEGIN
-		IF a > b THEN
-			result := a;
-		ELSE
-			result := b;
-		END;
-		RETURN result;
-	END;
-
-This code above may be rewritten in much shorter and cleaner manner using ternary operator:
-
-	PROCEDURE max(a, b: INTEGER): INTEGER;
-		RETURN a > b ? a : b;
-	END;
-
-### Implicit Type Narrowing
-
-Ternary operator supports [[Implicit Type Narrowing|eberon-implicit-type-narrowing]]:
-
-    TYPE
-        Base = RECORD END;
-        Derived = RECORD (Base) derivedField: INTEGER END;
-
-    PROCEDURE p(VAR b: Base): INTEGER;
-        RETURN b IS Derived ? b.derivedField : 0
-    END;        

doc/wiki/eberon.md

@@ -1,23 +0,0 @@
-**Eberon** is Experimental oBERON. It is my attempt to make a programming language in the right way (in my humble opinion of course) taking Wirth's Oberon as a start point.
-
-Eberon basically extends original Oberon (excluding additional [restrictions](#restrictions) below) so any valid oberon program is also a valid eberon program. A new syntax was introduced for extensions but I tried to maintain the original syntax flavor (e.g. CAPS).
-
-### Extensions
-* [[Methods|eberon-methods]]
-* [[Record Constructors|eberon-record-constructor]]
-* [[Strings|eberon-strings]]
-* [[In Place Variables|eberon-in-place-variables]]
-* [[Implicit Type Narrowing|eberon-implicit-type-narrowing]]
-* [[Dynamic Arrays|eberon-dynamic-arrays]]
-* [[Associative Arrays|eberon-associative-arrays]]
-* [[FOR..IN loop|eberon-FOR..IN]]
-* [[Array initializers|eberon-array-initializers]]
-* [[Array indexOf() method|eberon-array-methods]]
-* [[Record fields read-only export|eberon-record-fields-read-only-export]]
-* [[Procedure call result can be denoted|eberon-procedure-call-result]]
-* [[Operator NEW|eberon-operator-NEW]]
-* [[Ternary operator|eberon-ternary-operator]]
-* [[Syntax relaxations|eberon-syntax-relaxations]]
-
-### Restrictions
-* [[Non-VAR arguments are read-only|eberon-non-VAR-arguments-are-read-only]]

doc/wiki/home.md

@@ -1,35 +0,0 @@
-### The goal of the project
-I could formulate the goal as "to have traditional static-typed language on the Web". But more realistically it is: to built my own compiler (never did it before but always wanted). Also I wanted to [[experiment|Eberon]] with my own language.
-
-### Demo
-You can try the compiler online [here](http://oberspace.dyndns.org/oberonjs.html). You can compile more than one module at a time: modules should be separated by spaces or new lines and imported modules should be placed before dependent ones. 
-
-### How to use
-You can use the project as any other JavaScript library. There is no third-party dependencies. The project has been developing using nodejs, you might need to accommodate nodejs source modules in your project if you want to use nodejs. All source code is under src/ folder. Compiler entry point is `oc.js`.
-
-The repository contains pre-compiled JavaScriprt code of the compiler (ready to run) in .zip [archive](../../bin/compiled.zip). This code is needed to self-compile the compiler (from Oberon sources) for the first time.
-
-Python 2.x or 3.x is required. [build.py](../../build.py) script is used as a helper for different tasks:
-* build a test html page locally and see how it works
-    ```
-    ./build.py html
-    ```
-    this will create `_out/os.js` (glued nodejs modules) and `_out/oberonjs.html`. Open oberonjs.html in the browser and try the compiler!
-* compile Oberon source file(s)
-    ```
-    ./build.py compile file.ob
-    ```
-See other functions with "./build.py --help".
-
-### State of development
-* Proof of concept: Oberon modules compile to JavaScript and can be executed in web browser.
-* No SYSTEM module.
-* All included tests are passing.
-* Please report bugs or any deviations from language report.
-
-### Implementation details
-* [[JS module|JS-module]]
-* [[Report refinements|Original-report-refinements]]
-* [[Compiler options|compiler-options]]
-
-### [[Experiments|Eberon]]