No gotos. Instead, I try to provide constructs/commands that should make them unnecessary if you know how to structure your code decently. I do provide labels and labelled-break/continue:

foo: while(...) {
   bar: while(...) {
      while(...) {
         break; // break from the innermost loop (or switch)
         continue; // continue the innermost loop (or switch)
         break foo; // break from the "foo" loop (or switch)
         continue bar; // continue (skip to next iteration of) the "bar" loop (or switch)
      }
   }
}
One person suggested that "do goto start { ... }" would be more readable, though personally I prefer to leave that word out of the language. I suggested "do @ start {" or "do start {" ... I like "do start" or "do(start)" because I think it reads well enough (and yeah, you might have to know about this construct in the first place; but that's what it means to know a language. Stuff can be obvious "enough" without having to have a built-in readme I think). ... Nevertheless, opinions?

You are probably right. One reason I liked it (other than that Go uses it) is that the infinite loop is just "loop { ... }", but without another keyword. Otherwise "while(true) { ... }" is easily detectable. "Arr" is some array variable. In other languages this sometimes looks like "foreach(var in arr)" (I used shortened names so as to not totally give away stuff; but perhaps people have seen that mechanism, or perhaps the code itself would make it clear enough). I do think that perhaps a version of the "for" that mirrors TI-BASIC could coexist and make some code easier to write (e.g. "for(x,1,10)" versus "for(x=1;x<=10;x++)"). To keep things simple, the for is also used for "foreach" loops in some languages; and with that, I figured that allowing it to have just a condition (or perhaps have nothing to signify a "forever" loop) would not be much of a stretch ... but I admit that things like "while" and "do while" read much better.

I can stick with the standard setup, but perhaps keep extra options for "for":

while(c) { ... } // loop while c is true
until(c) { ... } // loop until c is true
do { ... } while(c); // do ... and then repeat while c is true
do { ... } until(c); // do ... and then repeat until c is true
do { ... } // do "forever" (useful)
for(init; test; update) { ... } // C++/Java/C# "for"
for(var, start, end, inc) { ... } // BASIC "for" (optional "inc")
for(var : array) { ... } // "foreach" (probably added in later); possibly also
// work with funcs/cofuncs where the last of the return-values is a bool
One thing I would like to provide is a way to start a loop in the middle somewhere to avoid having to use duplicate code before the loop and within the loop (trust me, everybody runs into this sooner or later):

// "A" (a large chunk of code) is duplicated to do this:
A;
while(C) {
   B;
   A;
}

// My solution (just as it reads, i.e. begin at label "start"):
do(start) {
   B;
start:
   A;
} while(C); // ...but repeat the WHOLE loop "while C" is true

// A common solution (but requiring "loop manipulation"):
do { A; if(!C){break;} B; } // !C is evil

A few days ago, I made a post (elsewhere) re-debating the syntax for using & declaring arrays and pointers; but I take it back (post deleted)! ... I was about to replace it with a post asking opinions on whether to use standard order (e.g. {*a[j]} is resolved to either {(*a)[j]} or {*(a[j])} depending on the datatype); but I just answered that question by myself when I realized that OPIA inserts derferences etc. automatically if the context is clear. This means that {a*[j]} can be shortened to {a[j]}, assuming that "a" is a pointer to an array so that the compiler would know that the "*" is implied. The reasons for not allowing "*" to be in front and "[]" to be in back (even though the compiler could determine the correct order of evaluation from the type) is the following: since {a*[j]*} can be shortened to {a[j]*}, then the other form would have to mean that {**a[j]} can be shortened to {*a[j]}, which means that something like {*a[j] = *b[k]} would could be ambiguous!!

If all that is confusing, then just consider this a recap on the syntax for array & pointer declaration/usage:
*[]byte x; // pointer to array of bytes
[]*byte y; // array of pointers to byte
byte b;

x[i] = b; // short for x*[i] = b;
y[i] = b; // short for y[i] = &b;
y[i]* = b; // no shorthand

b = x[i]; // short for b = x*[i];
b = y[i]; // short for b = y[i]*;The rule is to FIRST insert derferences "*" so that array-indexing "[]" (and dot ".") makes sense (thus {x[j]} is ALWAYS {x*[j]}), and SECONDLY to make the right-side suitable for the left side. The only issue with this it creates asymmetry (note the differences between {y[j] = b} and {b = y[j]}). This is not fixable because {&b = ...} is illegal anyway, and I'm set about having assignment-to-pointer always give an address (plus it allows values to be passed "by reference" more transparently).

EDIT: I am going to change the form a bit to be closer to how it was before (i.e. still use the "cofunc" keyword). I am going to update the overview to reflect this, and modify this (and previous posts) to reflect it. TO ANSWER THE QUESTION (with modifications applied):

cofunc T(byte x : byte) { // THIS SHORT-HAND FORM...
   for(byte last = 0; true; last += x) {
      yield last;
   }
}

struct T { // ...REALLY MEANS THIS
   cofunc(byte x : byte) {
      for(byte last = 0; true; last += x) {
         yield last;
      }
   }
}

t := T{}; // make a T variable
t(1); // 0+1 = 1
t(2); // 1+2 = 3
You can also name cofuncs, and have multiple of them in one struct:

struct Foo {
   byte x;
   cofunc f(byte y) { ... }
   cofunc g(char c) { ... }
}

f := Foo{1}; // x
f.f(2); // y
f.g('H'); // c
Embedding cofunc-definitions in a struct causes the struct to store the data needed to allow "yield" commands to work (i.e. local variables [like "last"], and the point of execution to continue from after the yield). In this case, the cofunc is anonymous (has no name), hence "t(1)" in the first part versus f.f(2) in the second.

Those tools certainly make stable and effective parsers; but I've seen the code for some of them (I do not recall which), and it looked very generated ... I prefer to do it on my own for the same reason that some people prefer to code in assembly. Sure those tools make it a lot easier and are already proven to work perfectly, but I don't think that necessarily makes them "better". Thought it is ridiculous code everything from scratch when the tools are already provided and proven; but being able to master those techniques means that you know when it might be better to make a custom version yourself (e.g I use my own LinkedList class because I found that java.util.LinkedList concatenates lists by converting them to arrays first!). Also, sometimes its better to have a custom structure that has all the general purpose features removed or works as needed without having extra layers ... but lets just settle on that I am doing it all manually because that's part of what makes it mine. And trust me, I know what it takes (experience and research) to make a solid parser & compiler, and how to do it efficiently (e.g. recursive decent, predefined Tokens with flags marking precomputed aspects, good parse-tree constructs, and keeping things modular). ... If anyone can do it, I can. I want to DO this.

The "change in grammar" from before was also a big change in the semantics of the grammar. The language was also particular about what could be contained where (e.g. whether classes, functions, etc. were abstract, virtual, static, etc.). After it was parsed, I also had to check for integrity between classes in regards to inheritance (things that had to be consistent or exclusive, etc.). This is also a sign that the grammar was not of a simple form ... which is one of many reasons that I like the Go-ish style much better than the C++/C#/Java style for a polymorphic language (especially one geared to such a low-level!)

Thanks for clarifying (I just thought that Omnimaga & Cemetech were just different sites, though both more communal that ticalc.org). I think that your suggestions would do me/OPIA well when it is ready to present. However, it's not ready to say "here it is!" ... but in announcing that it is upcoming, or allowing other to participate in the design (or discussion thereof), it would be beneficial to make it more readable / visual / involved / etc. Let me take just ONE paragraph to explain why this has not been much of the case yet (and then I will explain where/when this will come into play more):

The reason that my approach is so different from that of Axe (etc.) is that it is NOT a bunch of features crammed together. I have done my best to analyze features for their power, efficiency, usability, etc., doing my best not to include anything just because it looks nice or is familiar, etc. ... I am using strong principles of programming language and compiler theory to design a language that is as simple, expressive, powerful, understandable, and unrestricted as possible (which means "Ooh, can you put X into the language? I like X" has less sway than all those other factors). For example (skip rest of paragraph if you don't want one), questions about closures and coroutines led me to consider their necessity versus other techniques versus efficiency. Upon finding that they require the same internal mechanisms, I provided the "cofunc" as a clean and efficient way to do either, removing some of the headache and overlap that either present in their typical usage.

WHEN THE LANGUAGE IS IN PLACE (and at least on its WAY to being developed [e.g. the design already resolved]), then the language will need a LOT of contribution! Unlike Axe & Grammer, OPIA will NOT have any functions or libraries built into it. Using the core language, libraries (for graphics, input/output, math, OS calls, etc.) be written to extend the language by (1) tying directly into other tools/OS's, (2) providing direct access to other assembly resources, (3) embedding (hiding) assembly code into functions, or (4) using pure OPIA code to design new constructs, tools, etc. One is NOT required to know anything of assembly in order to use OPIA, since such integration techniques are only provided so that it CAN tie directly into other already existing tools (no matter where they came from). When I can provide something which can generate runnable code, I will provide some basic functionality for printing etc.; but I intend to involve as many people as want to participate when it comes time to come up with some sort of standard(s) and/or write some of the libraries that people are going to want. THIS is where people can be actively and freely involved in developing the language (through expansion) ... I, however, will design the core language (which I am mostly done with anyway). I will most certainly need to provide some more friendly documentation.

So far, I've decided that posting updates and opening things up for discussion is better than just doing it in the dark, since (1) I can get meaningful feedback from anyone willing to discuss internal theory/design, (2) perhaps I can find what would/would not be "acceptable" for people wanting to use the language, (3) people can see active design and get an idea for what is to come, while (4) building up a larger group of followers who will be anxious to help test it and develop the language further

EDIT: Perhaps I will provide some better examples before then though, so people can see what it would look like etc.

Ok, I've made an update:

 * Anonymous fields DO bring their methods into the containing struct (i.e. they can be used to fulfill interface requirements)

 * Changed "virtual methods" to "method pointers", and altered the syntax from "func blah(...)" to "func(this,...) blah" (so that they just act as special function-pointers). There is also no "declared within" paradigm (i.e. the "with or without a body" thing), though they MAY be given a default value just like anything else (e.g. " ... = func(...) { ... }").

 * Made some minor formatting adjustments with the changes (shortened some examples, but added some others)

I did not mention it in the overview, but bridge-functions will have to be used to map non-initial anonymous fields to their methods when they are used with interfaces.