FoodBanter.com - unplugging...

In alt.support.diabetes Robert Miles > wrote:
> On 9/25/2010 12:52 AM, Chris Malcolm wrote:
>> In alt.support.diabetes Ellen > wrote:
>>> "Chris > wrote in message
>>> ...
>>>> In alt.support.diabetes Ellen >
>>>> wrote:
>>>>> "Chris > wrote in message
>>>>> ...
>>>>>> In alt.support.diabetes Ellen >
>>>>>> wrote:
>>>>>>> "Chris > wrote in message
>>>>>>> ...

>> Coroutines differ in a number of ways from subroutines. For example
>> they're allowed to exit when they're only part finished, to be resumed
>> from where they broke off when the next coroutine call is made. That
>> allows a very natural and elegant programming solution to the kind of
>> interleaved multiple data hierarchies I've been describing.
>>
>> Another way of handling the same kind of data structuring problem
>> elegantly (but not quite as elegant as with coroutines) is by using
>> software interrupts which invoke the hardware interrupt mechanisms of
>> the computer by means of programmed software. In the early days of
>> computers not all computers had such a facility in the hardware of the
>> computer. These days (almost) all computers have it, but its use is
>> usually restricted to the systems programmers who program the
>> operating system.
>>
>> I brought in the idea of coroutines because folk were discussing
>> esoteric aspects of certain kinds of programming such as programming
>> in assembly language and hexadecimal. I just wondered if there were
>> any folk around who'd done enough serious complicated assembly
>> language coding to have heard of or even used coroutines.
>>
>> Seems not. Just wondered :-)

> I've used hexadecimal and done some assembly language programming,
> but that could have easily been before coroutines became known.
> I've never seen them mentioned before this thread. However, I
> have seen some multi-thread programs, not in assembler, that were
> written to have some parallel capability by being able to run on
> more than one core of a modern multi-core CPU at the same time.
> Perhaps a new name for the same thing?

No. See:

http://en.wikipedia.org/wiki/Coroutine

"Coroutines are computer program components that generalize
subroutines to allow multiple entry points for suspending and resuming
execution at certain locations. Coroutines are well-suited for
implementing more familiar program components such as cooperative
tasks, iterators, infinite lists and pipes.

"The term "coroutine" was originated by Melvin Conway in a 1963 paper."

[...]

"To implement a programming language with subroutines, only a single
stack that can be preallocated at the beginning of program execution
is needed. In contrast, coroutines, able to call on other coroutines
as peers, are best implemented using continuations.[citation needed]
Continuations may require allocation of additional stacks and
therefore are more commonly implemented in garbage-collected
high-level languages.[citation needed] Coroutine creation can be done
cheaply by preallocating stacks or caching previously allocated
stacks.[citation needed]"

The big difficulty with coroutines is that some computer hardware
instruction code sets made it a bit awkward to implement them,
e.g. upwards of half a dozen instructions rather than one or two, and
few programming languages reflected that basic native capability of
the instruction set hardware up into the programming language
capabilities.

It's a somewhat tricky concept which is rarely used, hence for
compiler writers under time and financial pressure it's probably the
first thing to be dumped from the original spec. If it was even in
the original spec. Because it's rarely used and not much known.
Despite being extremely useful, wonderfully elegant, and great fun :-)

So at levels above assembly language if they're used
they're often a rather unpleasant fudge.

I only used them once in my programming career. Re-organising a
complex buffering and batching problem in terms of coroutines made it
possible to produce a simple, elegant, easily understood, and easily
debugged, version of code which had previously been implemented in
terms of procedures. Which meant that a great deal of horrible
exception handling had to be patched into the coding of the primary
case around which the procedural structure had been built. Which was
so horrible that half a dozen programmers had each spent months or
heavy overtime trying to make it work, but instead had made it even
more complicated and difficult to debug.

I was the last of the programmers delegated to make the horrible thing
work. I came to realise that the problem was not only that the data
structure was not properly reflected in the code structure, but that
no purely procedural code structure could.

This was in the heyday of the theoretical programming controversies
over whether it was theoretically possible to code every possible kind
of programming problem without too much inelegant difficulty in a
language without the infamous structure-breaking "go to", the battle
between the high level language modernisers and the die-hard assembly
language enthusiasts.

So the fact that the theoretical answer was "yes" -- provided
coroutines were reflected into the higher level language tool-kit --
was a topical point of discussion among computer systems theoreticians
at the time. Which I wasn't, but I followed the debate with great
interest, which was how I learned about them.

--
Chris Malcolm