(Answering Mr. Eschenlauer's questions about coexpressions.)
To answer the question, consider this short extract from the
book example (I have uppercased the coexpression names for
clarity):
WORDS := create word()
LINES := create reader()
...
procedure word()
...
while line := @LINES
...
end
procedure reader()
while read() @ WORDS
end
Your "pipe" conceptualization is not too bad. In this
example it works as follows:
Inside of LINES:
read() @ WORDS
is conceptualized as "write a value to the pipe that has the
WORDS task at the other end, then pause my task until
woken up by somebody."
Inside of WORDS:
line := @LINES
is conceptualized as "start the LINES task, then wait around
trying to read from the pipe LINES will write into.
They alternate like this, each pausing and starting the
other. (Also in the full example, tasks WORDS and WRITER are
dancing together.)
Now the question you might ask is: why bother having the
transmit-to-coexpression feature? Can't we easily recast
the code to NOT use this feature?
For example, you might easily rewrite procedure reader()
within LINES to be a generator, like this:
LINES := create reader_1()
...
procedure word()
...
while line := @LINES do # Unchanged from original
...
end
procedure reader_1()
suspend |read() # Orig: while read() @ WORDS
end
With reader_1() you get the same result as with the original
reader(), but the execution flow is somewhat different. Turn
on &trace to see the difference.
In the modified, no-transmit version, the reader_1()
procedure is suspending and resuming. Reader_1() transmits
its values "through the pipe" every time is suspends out of
the the top level of co-expression_3 task.
In the original example, what DOESN'T happen is a lot of
procedure call/return (or suspend). After the
co-expression_3 task has started and reader() has been
invoked inside, reader() does not return or suspend until it
is ready to finish off its enclosing task. Values are
transmitted "through the pipe" directly.
In the original reader(), the expression "result @ WORDS"
achieves the same effect as suspending from the top level.
However you could transmit a result from anywhere, even deep
down inside a call stack. This is what the feature is good
for. You can "suspend" out of a coexpression without having
to be executing the top level.
And to be unaware of the invoking task, you can write
"result @ &source".
-- Michael Glass
University of Illinois at Chicago
_______________________________________________
Unicon-group mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/unicon-group
