fork()

[Evan Simpson]

Tim Peters wrote in message <000601beb56d$829f6720$319e2299 at tim>...
> [Evan Simpson]
>> ...
>> Perhaps I'm being naive, but I have the impression that when cycles
>> arise it's usually a simple accident and easy to fix once you know
>> you've done it.

> Exactly so:  you're being naive <wink>.

I rather thought so, although I did know about Guido's "native" cycles
already.

> Stuff "like that" pops up in all sorts of apps.  With practice you learn
> ways around it most often.  I've noted more than once that the resulting
> cycle-free design is often more robust and comprehensible than its cyclic
>ancestor, so I think it's a fruitful exercise to do this; doesn't always
> succeed, though, and when you're in a rush it's a pain in the ass to have
to
> bother.

"easy to fix" was a bit of an overstatement, but this is essentially what I
meant.

>> Would it be possible (and not too expensive) to distinguish actual cycle
>> members from dangly bits (maximal non-cyclic subgraphs)?
[Interesting SCC approach snipped]

> What you suggest is weaker, effectively lumping the SCCs into two gross
> classes (singletons and non-singletons), and nuking the latter first.

Sorry if I was unclear, but that's not what I meant by "dangly bits".
Rather, take the set of nodes from which you cannot reach a cycle.  Their
subgraph is a union of DAGs, which can be released normally.  In your
example, handing "c" a reference to "d<->e" converts it from a dangly bit to
a cycle-bridge.

On the other hand, the SCC approach does look stronger than this, since it
can handle cycle-bridges as well.  I'll happily take your word that
SCC-counting is likely to be too much trouble, but how about just doing an
SCC-analysis once M&S has discovered a cycle?  If this is all happening in
the background, with no deadlines, and with rare, naughty data structures,
then it doesn't have to be terribly efficient.

and-my-non-existent-code-can-be-maximally-inefficient-if-it-wants-ly y'rs
Evan Simpson