[Python-Dev] ob_refcnt access

[Tim Peters]

[Mark Hammond]
> Im a little unhappy as this [stackless Python] will break the Active
> Debugging stuff ...
> ...
> So the solution MS came up with was, surprise surprise, the machine stack!
> :-)  The assumption is that all languages will make _some_ use of the
> stack, so they ask a language to report its "stack base address"
> and "stack size".  Using this information, the debugger sorts into the
> correct call sequence.

Mark, you can't *really* believe Chris is incapable of hacking around this,
right?

It's not even clear there's something to be hacked around, since Python is
only Python and there's nothing Christian can do to stop other languages
that call into Python from using the machine stack, or to call other
languages from Python without using the machine stack.  So Python "shows up
on the stack" no matter what, cross-language.

> ...
> Bit I also understand completely the silence on this issue.  When the
> thread started, there was much discussion about exactly what the
> hell these continuation/coroutine thingies even were.

The Fuchs paper Sam referenced explained it in simple C terms:  a
continuation is exactly what C setjmp/longjmp would do if setjmp saved (&
longjmp restored) the C stack *in addition* to the program counter and
machine registers (which they already save/restore).  That's all there is to
it, at heart:  objects capture data state, continuations capture control
flow state.  Whenever the OS services an interrupt and drops into kernel
mode, it captures a continuation for user mode -- they don't *call* it that,
but that's what they're doing, and it's as practical as a pencil (well,
*more* practical, actually <wink>).

> However, there were precious few real-world examples where they could
> be used.

Nobody asked for any before now <0.5 wink> -- and I see Sam provided some
marvelous ones in response to this.

>  A few acedemic, theoretical places,

I think you undervalue those:  people working on the underpinnings of
languages strive very hard to come up with the simplest possible examples
that don't throw away the core of the problem to be solved.  That doesn't
mean the theoreticians are too air-headed to understand "real world
problems"; it's much more that, e.g., "if you can't compare the fringes of
two trees cleanly, you can't possibly do anything harder than that cleanly
either -- but if you can do this little bit cleanly, we have strong reason
to believe there's a large class of difficult real problems you can also do
cleanly".

If you need a "practical" example of that, picture e.g. a structure-based
diff engine for HTML source.  Which are really trees defined by tags, and
where text-based comparison can be useless (you don't care if "<LI>" moved
from column 12 of line 16 to column 1 of line 17, but you care a lot if the
*number* of <LI> tags changed -- so have you have to compare two trees *as*
trees).

But that's a problem easy enough for generators to solve cleanly.  Knuth
writes a large (for his books) elevator-simulation program to illustrate
coroutines (which are more powerful than generators), and complains that he
can't come up with a simpler example that illustrates any point worth
making.  And he's right!  The "literature standard" text-manipulation
example at the end of my coroutine module illustrates what Sam was talking
about wrt writing straightforward "pull" algorithms for a "push" process,
but even that one can be solved with simpler pipeline control flow.

At least for *that*, nobody who ever used Unix would doubt the real-world
utility of the pipeline model for a nanosecond <1e-9 wink>.

If you want a coroutine example, go to a restaurant and order a meal.  When
you leave, glance back *real quick*.  If everyone in the restaurant is dead,
they were a meal-generating subroutine; but if they're still serving other
customers, your meal-eating coroutine and their meal-generating coroutine
worked to mutual benefit <wink>.

> but the only real contender I have seen brought up was Medusa.  There were
> certainly no clear examples of "as soon as we have this, I could change
> abc to take advantage, and this would give us the very cool xyz"
>
> So, if anyone else if feeling at all like me about this issue, they are
> feeling all warm and fuzzy knowing that a few smart people are giving us
> the facility to do something we hope we never, ever have to do. :-)

Actually, you'll want to do it a lot <wink>.  Christian & I have bantered
about this a few times a year in pvt, usually motivated by some horrendous
kludge posted to c.l.py to solve a problem that any Assistant Professor of
Medieval English could solve without effort in Icon.  The *uses* aren't
esoteric at all.

or-at-least-not-more-than-you-make-'em-ly y'rs  - tim