Actually, they do need to (and did) have their types declared, just like any other variable. The ":=" operator tells the compiler that a variable is being both declared and initialized, and to infer the type from the initialization value. At first I was not sure about having both "=" and ":=" operators, but I've found that it indeed makes it easier to code!

cofunc generate(...) { ...i := 2;... } // word i = 2;

cofunc filter(func(:word) in ...) { ...i := in();... } // word i = in();

cofunc sieve(...) {
   ...in := new generate();... // *generate in = new generate();
   ...prime := in();... // word prime = in();
}

func main() { ...nextPrime := sieve();... } // sieve nextPrime = sieve();The only bearing on "new" is that, without it, that function would overwrite the same static variable each time; so I used "new" to say "allocate new memory for this" (which actually makes the variable a pointer, since that returns an address ... another nice thing about automatic stuff like that)

Sort of... they are different types altogether. A 'Foo' can be assigned values from the enum declaration (or from other Foo variables). A 'switch(Foo)' just borrows the labels of Foo, but assigns separate values (i.e. addresses of actual cases in a switch somewhere). In fact, given two 'switch(Foo)' variables g1 and g2, g1 and g2 use DIFFERENT values because they are associated with different switches. That is, g1.X is the address of "case X" where g1 is switched on (switch(g1) { case X: ... }), and g2.X is the address of "case X" where g2 is switched on. Therefor, though they appear to have the same type, g1 and g2 cannot be assigned each other's values, neither can they take values from a 'Foo'.

enum Foo {X,Y,Z}
switch(Foo) g1, g2;
Foo f;
...
switch(f) { ... } // f is used as an INDEX for a look-up-table for this switch
...
switch(f) { ... } // ...and again in this switch.
...
switch(g1) { // No index. This is simply 'goto (g1)'
   case X: // g1.X refers to the address of this location in code
   case Y: // g1.Y refers to this address, etc.
   ...
}
...
switch(g2) { ... } // Likewise, g2 will have it's own switch, and it's own X,Y,Z
...
switch(g2) { ... } // ILLEGAL! (g1 and g2 are variables for ONE specific switch)
...
g1 = g2.X // ILLEGAL, because that would cause the switch on g1 to goto g2's "case X"
... There is really no point in defining an enum just to make a switch variable on it. The code above might as well have just said 'switch{X,Y,Z} g1, g2;'. The only reason I allow it is that, supposing you already HAD an enum defined, and the cases were related conceptually to the enum, then you might as well just use the same labels (and rather than copying each label, you can just plop the enum name into the switch-variable type). Again, a switch "on" an enum only mimics that enum by using the same labels for its values. ... But since it's only a mimic (switch variables cannot interact with other variables because they each use a unique set of case-addresses), is it worth allowing the mimic at all? That is, I could just allow the switch{X,Y,Z} g1 type of declaration if that would be less confusing.

EDIT: All you really need to look at is this table (and yes, I did just totally scrap the old post for this):

   switch(value) { case 1: ... 2: ... 3: ... }

   ---Jump Table---   --Look-Up-Table--   --Direct_Address--
    ld a,(value) ;3    ld hl,cases   ;3    ld hl,(value)  ;3
    ld ($+4),a   ;3    ld bc,(value) ;4    jp (hl)        ;1
    jr N         ;2    add hl,bc     ;1
    jp case_1          jp (hl)       ;1
    jp case_2         cases:
    jp case_3          .dw case_1
                       .dw case_2
                       .dw case_3
   ----------------   -----------------   ------------------
   = 8 (+3 per case)  = 9 (+2 per case)   = 4 bytes used (+0)

Since a jump-table is clearly the worst choice, the only real choice now is whether I want uber-efficiency (using direct addresses) or flexibility (using look up tables). I either I provide enums with even values (and hidden) so that they are efficient to use with switches, or I provide "selectors" which are each to be used with exactly ONE switch each, and contain actual case-addresses as values. The big difference is that an enum could be USED in any switch, but a selector IS the control for a particular switch. ... Perhaps I could provide both? Enums are flexible and better as values (being one byte each), while selectors are uber-efficient when used as case-selectors. A selector would be declared somewhat like an inline enum:
enum eFoo {X,Y,Z} ... eFoo a; a = eFoo.X;
selector(X,Y,Z) sFoo; sFoo = X;

(My previous suggestion about modeling a switch as a function with multiple entry points comes from the idea that modifying an address directly and jumping to it sounds just like a function-pointer; but since switch-cases can fall through to the next case, perhaps a function with multiple entry-points, being several functions smashed together but with an entry-table as well (stored as a function-pointer-array) ... but I resolved that by just using a look-up-table instead).

EDIT-EDIT: Here is a possible solution: I could provide both simply by providing the enum, and "switch on an enum" variables:

   // enum usage
   enum Foo {X,Y,Z}
   Foo f1 = Foo.X;
   f2 := Foo.X;

   // switch "on Foo"
   switch(Foo) g1 = g1.X; // "g1.X" because g1 uses specific case-addresses
   g2 := switch(Foo).X; // g2 uses case-addresses that DIFFER from g1...
   g1 = g2; // ...which means that THIS IS NOT ALLOWED

   // switch on anonymous enum
   switch{X,Y,Z} h1 = h1.X;
   h2 := switch{X,Y,Z}.X;

   // Later on, g1 is used in a switch statement:
   switch(g1) {
     case X: ...
     case Y: ...
     case Z: ...
     // NO default code (all cases are explicit)
   }

The switch "on enum" variables only use the values of the specified enum as labels for addresses of a specific switch-construct. Therefor, each switch variable has its own set of values, and thus they cannot be assigned each other's values (hence the "varA = varA.value", and the type is singular to each variable). Each switch variable may only be used in ONE switch-statement.

Note: The parser can tell the difference between each use of "switch" by the placement of parenthesis, brackets, and identifiers:
 - switch(ident) ident
 - switch{list} ident
 - switch(ident) {

...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

=== 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

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);

A random list of points discussed previously on other forums (modified):

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.

MEMORY MANAGEMENT - No Garbage collector will be built-in. However, functions can be written which will enable the "new" (and "delete") operators for the language. The idea is that any kind of memory management can be plugged in (whether coded manually, or already part of the platform/OS). As for static allocations, there are preprocessor directives whuch can be used to signify sections of "same RAM" which the compiler will use for larger things that lack initialization values.

VIRTUAL FUNCTIONS - I was originally going to have the compiler just KNOW when functions should be virtual/late-bound because of the overridden definitions (like Java). However, requiring one to explicitly say which functions are virtual (like C#/C++) means that a the internal representation of a class can be determined without having to look at other code. This is important because OPIA allows you to specify an address where something is already stored (e.g. precompiled or otherwise already existing) rather than allocating space for it otherwise.

ENVIRONMENT DEPENDENCIES - If a program is completely generic (i.e. nothing platform-specific), then it will run anywhere (directly on the bare hardware). Standard representations of functions, arrays, etc. also allow things to be picked out explicitly and used with new code. The whole compilation process is going to be very modularized, such that it can be used an API by other tools (e.g. an IDE which uses the compiler itself to highlight syntax and find errors, but without doing a full compile).

FEATURES - OPIA will ONLY include features which would be difficult to do with the language otherwise, which can be implemented using close to the same overhead NECESSARY as if done manually, and which do not add unnecessary complexity to the language. For example, I was going to have classes & interfaces (I will post more about that later) because one would HAVE to use late-bound functions and virtual tables to simulate that anyway; but I have even replaced classes & inheritance with structs and simpler interfaces because it makes the language simpler, adds more power/flexibility, and provides a much closer representation of the underlying mechanisms used. OPIA will NOT include operator overloading, bounds-checks (or any built-in error handling), excpetions, or assertions (though interpreted aspects can be used to compile code dynamically). I was going to provide parametric types (using type-erasure, since that provides a single representation for each thing); but with the new Go-style interfaces, OPIA might be fine without them ... maybe in the future, but I'm not promising it.

VALUE PASSING - Always pass-by-value. I was going to provide reference-types, which use pointers internally, but now that I've switched to a simpler Go-like setup, one can just use pointers directly as needed.

NAMING - I really do not see what it wrong with the name "OPIA" (except for the similar spelling to "opium"); but the only other name suggested so far that I even like at all was "Candu" (Malay for "opium"). No Z++, because there are too many letters and pluses and sharps etc. already. No "TI" anything, because it will run on ANY z80 machine (though heck yes, TI's are the focus) ... but seriously, is "OPIA" such a bad name? (Object-oriented Pre-Interpreted Antidisassemblage ... though admittedly, the Go-style is polymorphic and object-based without being truely object-oriented in the traditional sense).