In alt.support.diabetes Ellen K. > wrote:
> "Chris Malcolm" > wrote in message
> ...
>> In alt.support.diabetes Ellen K. >
>> wrote:
>>> "Chris Malcolm" > wrote in message
>>> ...

>>>> Having to have a lot of complex exceptions to the main line of
>>>> structured code is often a sign that you're trying to do the right
>>>> thing, which is to follow the logic of the data structures with the
>>>> procedural or subroutine delegation of the program code, but
>>>> something's gone wrong. That data strucure following works very well
>>>> when the data structure is categorically well structure. It fails when
>>>> you have to deal with two parallel or independent kinds of data
>>>> structures. In that case whichever data structure you follow with your
>>>> code, the other has be dealt with by a patchwork of messy exceptions.
>>>>
>>>> Unless instead of subroutines you use (tada!) coroutines -- a very
>>>> useful software control structuring trick available to the systems
>>>> assembler programmer, but rarely reflected into higher level
>>>> programming languages. It's a kind of simultaneous subroutine call and
>>>> exit, which allows the co-existence of neatly programmed parallel
>>>> control structures to follow parallel data structures.
>>>>
>>>> --
>>>> Chris Malcolm
>>
>>> The situation you describe sounds like the very beginning of the process
>>> needs to separately define the possible cases, then provide separate
>>> handling for each one.
>>
>> The classic data structure problem which coroutines solve very neatly
>> is the interleaved packaging problem which occurs in
>> telecommunications. Suppose your comms protocol only allows maximum
>> package sizes of 1 kilobyte at a time. So if you have lots of small
>> emails to send then a dozen might be put into one package. So one
>> package can will contain a number of emails. But if you have a large
>> email of say 20 kilobytes to send, then your large email will contain
>> lots of packages. So sometimes you have to unpack packages to get at
>> the emails inside, and sometimes you have to unpack emails to get at
>> the packages inside.
>>
>> That doesn't sound too hard a problem. But start adding in all sorts
>> of exception conditions, retransmission requests, missing package
>> problems, checksum failures at various levels, emails which contain
>> attachments inside them, packages which are wrapped up inside larger
>> transmission protocol packages, and it starts getting very messy.
>>
>> Hard to handle with classic data structures which insist on a simple
>> categorical structures where for example emails must either be parts
>> of a package, or alternatively packages must be parts of an email, but
>> not both. The same goes for classic program control structuring
>> methods such as procedural decomposition where control has the same
>> strict hierarchy of delegatation and return of control. It would be
>> like a management structure in which for some parts of the day your
>> boss tells you what to do because he's your boss, and at other times
>> you tell your boss what to do because you are his boss.
>>
>> --
>> Chris Malcolm

> I've never worked with that type of thing, only applications working
> directly with business data, mostly financial.

Type of data is irrelevant, it's what kind of structure it has. IIRC
at least one airline ticket reservation system had this kind of
problem and solved it with coroutines.

--
Chris Malcolm