What do you think of this generator syntax? [closed]

Question

I've been working on an ECMAScript dialect for quite some time now and have reached a point where I am comfortable adding new language features. I would love to hear some thoughts and suggestions on the syntax.

Example

generator {
    yield 1;
    yield 2;
    yield 3;
    if (true) {
        yield break;
    }
    yield continue generator {
        yield 4;
        yield 5;
        yield 6;
    };
}

Syntax

GeneratorExpression:
    generator  {  GeneratorBody  }

GeneratorBody:
    GeneratorStatements_opt

GeneratorStatements:
    StatementList_opt GeneratorStatement GeneratorStatements_opt

GeneratorStatement:
    YieldStatement
    YieldBreakStatement
    YieldContinueStatement

YieldStatement:
    yield  Expression  ;

YieldBreakStatement:
    yield  break  ;

YieldContinueStatement:
    yield  continue  Expression  ;

Semantics

The YieldBreakStatement allows you to end iteration early. This helps avoid deeply indented code. You'll be able to write something like this:

generator {
    yield something1();
    if (condition1 && condition2) 
        yield break;
    yield something2();
    if (condition3 && condition4) 
        yield break;
    yield something3();
}

instead of:

generator {
    yield something1();
    if (!condition1 && !condition2) {
        yield something2();
        if (!condition3 && !condition4) {
            yield something3();
        }
    }
}

The YieldContinueStatement allows you to combine generators:

function generateNumbers(start) {
    return generator {
        yield 1 + start;
        yield 2 + start;
        yield 3 + start;
        if (start < 100) {
            yield continue generateNumbers(start + 1);
        }
    };
}

Answer 1

Yes it would be nice to get a better idea of the purpose of the break/continue idea.

Seems there's an argument about utility of iterators. More generally, generators. Lets be clear @M28 is utterly and conclusively wrong. I suggest e goes out and writes all er code as a callback, without reading data from a file. Because yes the fundamental purpose of operating systems is to control invert unusable callbacks (interrupts) delivering data so client code can be master instead of slave, reading the data as required by the program, not when required by external conditions.

The extreme difficulty of writing callbacks is clearly demonstrated in complex application by the abuse of threads to obtain control inversion, when in fact no concurrency is actually desired, simply because the C systems programming language fails to support it.

The technical reason for the intractability of callbacks is the lack of support for maintenance of state. Modern processors provide a stack which integrates control flow (program pointer) and local data to support subroutine calling: a master/slave relation. In fact the lack of control exchange in the model is also it's primary limitation. But starting off with a slave is even worse than this misdesign!