In the current Icon / Unicon implementation, the state of every generator
is
stored in variables in the C stack. For exmple, when Icon evaluates
every write (!"ABC", 0 to 9)
the C function that evaluates the unary "!" operator has a local variable
that tracks the state of this generator. In turn, the C function that
implements "!" will call the C function that implements 0 to 9. The C
function that implements the Icon "to/by" expression has a local variable
that stores how far we are in this sequence.
But what happens when a co-expression transfers control to another
co-expression? This can happen during co-expression activation, or when a
co-expression returns or fails. When control is passed to another
co-expression, the list of active generators changes. Does this require
that
the C stack change?
That is precisely what happens in the current implementation: each
co-expression has its own C stack. The function coswitch() is used to
change
the C stack to the one associated with the co-expression that will soon
gain
control. Needless to say, coswitch is extremely platform specific. All
implementations of coswitch use some assembler. The coswitch function
depends on the machine archetecture, the OS conventions, and even the
specific details of the compiler implementation. On some platforms,
switching the C stack is quite simple. On others, it is nearly impossible,
requiring that Icon / Unicon be implemented without co-exopressions.
Now imagine that generators saved their state data in the block regions,
instead of on the C stack. That is, imagine that the expression !"ABC"
would
allocate a block object that contains information indicating the last
value
generated, along with a method for generating the next generated value. If
this scheme was implemented, would there be any need for the coswitch
function?
|
