BOOLEANS - Booleans are a whole byte because it takes extra instructions to extract/insert just one bit, which adds more than just another byte to the program just for using it; so it actually saves space that way.

Hmm... So, for Boolean values, would it be faster on-calc if we just used single bytes and checked if they were (non-)zero ourselves?

As for the name, I like OPIA. I see nothing wrong with it. Everything else sounds good

REGARDING STRINGS (and a good sample of code prior to the Go-style reformation of the language):

There is no "string" type, but a character array (char[]) is used instead. String literals automatically convert to character arrays followed by a null value (zero). I wanted to have the + operator concatenate strings cleanly, and cleanly means not allocating a whole new array for EVERY concatenation. Java solves this using a "StringBuilder", which I could code (using OPIA code) as follows:

class StringBuilder {
    private class Node {
        public char[] string;
        public Node next;
        public Node(char[] s) { string = s; next = null; }
    }
     
    private Node head, tail;
    private uword length;

    public StringBuilder() { head = tail = null; length = 0; }

    public void concatenate(char[] string) {
        Node n = new Node(string);
        if(head == null) { head = tail = n; }
        else { tail = tail.next = n; }
        for(uword i = 0; string[0] != 0; i++) { }
        length += i;
    }

    public void merge(StringBuilder s) {
        if(s.head == null) { return; }
        if(head == null) { head = s.head; }
        else { tail.next = s.head; }
        tail = s.tail;
        s.head = s.tail = null;
    }

    public char[] toString() {
        uword pos = 0;
        char[] string = new char[length];
        for(Node n = head; n != null; n = n.next) {
            for(uword i = 0; n.string != 0; i++) {
                string[pos++] = n.string;
            }
        }
        return string;
    }
}

abstract class Object {
    public abstract void printTo([char[]] handler);

    public StringBuilder toString() { // intentionally misleading
        StringBuilder s = new StringBuilder();
        printTo(s.concatenate);
        return s;
    }
}

interface Comparable<T> where T : Comparable<T> {
    byte compareTo(T other); // interface members are inherently public abstract
} 

// The compiler then makes these conversions (and pretends that the resulting StringBuilder is "returned" by each):

char[] str;
StringBuilder sb;
...
sb  + sb;  // => sb.merge(sb);
sb  + str; // => sb.concatenate(str);
str + str; // => str.toString().concatenate(str);
str + sb;  // => str.toString().merge(sb);
str = sb;  // => str = sb.toString();
sb  = str; // => sb = new StringBuilder(); sb.concatenate(str);

=== AND NOW FOR A MAJOR CHANGE TO THE LANGUAGE ===

THIS IS WHERE I CHANGED THE LANGUAGE SIGNIFICANTLY TO BE
MORE LIKE GOOGLE'S "GO" LANGUAGE AND LESS LIKE JAVA/C#:

Basically I replaced classes & inheritance with a more powerful, flexible, light-weight model for interfaces & composition. This is a what makes Google's Go language a "fast, statically typed, compiled language that feels like a dynamically typed, interpreted language." It's a different approach to polymorphism, involving these changes:

(1) Replace classes with plain structs, but allow them to embed "anonymous" types which simulate a some inheritance using composition.
(2) Methods are declared separately (externally), and can thus be declared as needed and on ANY type.
(3) A datatype automatically implements an interface simply by having the required methods. For example, a function could taking a "Writer" interface could be given ANYTHING that has a "write()" method (like "duck typing"). This allows datatypes (structs) to implement interfaces without even "knowing" it, and without any overhead added to the type (struct).

It would have been silly NOT to do (2) and (3), since they simplify and add power to the language without any major underlying changes. The argument for (1) is that the "class" is removed because it becomes redundant: If you remove the method table from a class and store it separately, you have an "interface" (see chart below).

Class-based model (* denotes a pointer):

struct := [all the data of the struct]
table := [*method, *method, *method, ... ]
class := [*table, struct]
interface := [*table, *class]

New model: (same, but without "class", and *class becomes *object)

This new model provides better access to the underlying mechanisms, and results in simpler code! At the most fundamental level, polymorphism simply involves the use of method-pointers, which is what "virtual" methods are anyway. Thus, one could do it all manually just by storing or passing method-pointers directly (and given (2), method pointers would just be function-pointers, since the "this" argument would be explicit). However, passing an object along with it's methods is EXACTLY what the "interface" is already!

Here is some example code, with some obvious syntax changes made:

   byte x,y,z = a,b,c; // assignment in parallel
   *byte ptr; // ptr is a pointer-to-byte variable
   [5]byte arr; // arr is a static array of 5 elements (not a reference)
   []byte arrP; // arrP is a reference to an array (unassigned)
   *[]byte p2a; // pointer to array
   []*byte aop; // array of pointers
   a,b,c := 1,"yo",ptr; // declaration with type-inference (byte, []char, *byte).

   func f1(byte a, b : char) { ... } // function f1 takes bytes a & b, and returns a char
   func f2( : byte, char) { ... } // function f2 takes nothing, returns a byte and char
   func f3(byte a, b) { ... } // function f3 takes bytes a & b, returns nothing
   func(byte,byte,byte) x; // pointer to some func(byte a,b,c)
   func(byte a,b,c) y; // Same as above (using name-holders)
   x = func(byte a,b,c) { ... }; // anonymous function is declared and assigned to x

   struct A { byte x; } // an A has an x (someA.x)
   struct B { A; byte y; } // Composure: someB.x is short for someB.A.x

   interface foo { // interface foo defined as anything containing:
      foo1(:byte); // a method called foo1 which returns a byte
      foo2(byte); // ...foo2 which takes a byte and returns nothing
   }

   func A.foo1(:byte) { ... } // method for A implementing foo.foo1
   func A.foo2(byte b) { ... } // ... implementing foo.foo2

   A a; ... foo f = foo(a); // interface-instances are constructed around valid vars
   B b; ... f = foo(b); // Invalid, because b.foo1 is really b.A.foo1
   f = foo(blah,blahX,blahY); // overloaded interface instance:
   f.foo1(); f.foo2(5); // calls blah.blahX() and blah.blahY(5)

I later decided that I could allow functions to be declared within structs to designate "virtual functions". By doing so, a function-pointer is actually stored within the struct, with a default value pointing to the provided method body. Virtual methods CAN be used to fulfill interface requirements:

   struct Thing {
      byte x, y;
      func act(); // no method body (in list)
      func compute(:byte) {
         return x*y;
      }
   }

   func Thing.add(:byte) { return x+y; }
   func Thing.sub(:byte) { return x-y; }

   a := Thing{1,2,Thing.add};
   b := Thing(3,4,Thing.sub};

   a.act();   // calls a.add()
   b.act();    // calls b.sub()
   a.compute(); // calls Thing.compute() on a
   a.compute = Thing.add;
   a.compute(); // now calls Thing.add() on a
   b.act = a.compute;
   b.act();   // calls Thing.add on b

...And there it is. This forum should now be caught up (though much discussion is missing, I provided all the key points). The changes from Java/C# style (btw, I think C# is the best OOP language yet...) to a more Go-ish style (..but Go seemed more simplified and flexible, and more powerful at the low-level; and therefor more suitable for a z80 language) results in less overhead, MUCH less keywords, and NO TYPE HIERARCHY (as inheritance imposes)! In keeping with this simplification, I removed the public/private/protected mechanisms, and simply provide that lowercase entities are only visible within the namespace they are declared in (files may start with "namespace BLAH;"), structs & interfaces etc. may not be declared within eachother, nor may they contain "static" variables/entities (instead, these are declared directly within the same namespace). I was going to disallow nested namespaces and remove the "using [someNamespace]" mechanisms, but I think I can allow that anyway, since it would be the only real way to nest "static" things in a modular way ... but without having to use the "static" keyword

As always, all current documentation can be found at http://tinyurl.com/z80opia , but I will try to keep up to date here as well. You can view the source there and test it as you please (which would be much appreciated). Thanks everyone for participating

I haven't read all of this yet because I haven't had time, but I skimmed over the cofunctions section because I didn't understand them from the Wiki. From what I'm getting, they're the same as anonymous functions?

EDIT: I'm looking at the source, and in the Token file, should "volitale" be "volatile"?

Ahh, okay, now I understand. I was beginning to think that cofunctions and anonymous functions were synonymous, but now I see what they're for. That's really cool, actually. I'll definitely have to try something soon!

Personally I would think look-up tables are the best (I normally go for flexibility), but seeing as this is on the calculator, I would say direct addresses.

I was a little confused about that part (using switch statements as variables). If I had something like switch(Foo) g1 = g1.X; is that essentially initializing g1 as the type Foo while setting its value to Foo.X (i.e. Foo g1(Foo.X); in C++)? Then if I did switch(g1), case X would be the one executed?