GOTO w/ Python?

[Jerzy Karczmarczuk]

John Roth comments my observation concerning the relation between gotos
and continuations:

> >    ... in order to speak about genuine gotos *you don't need to think
> >    assembler*.
> >    What you need is to understand correctly the notion of continuation
> >    (something quite standard - again - in the Functional Programming
> >    world). This is a high-level model of "flat" branching, but may be
> >    used to more exquisite constructions, such as backtracking.
> 
> That's still not a goto in the classical sense. In the classical sense,
> a goto allows you to go to any statement. The point you're missing is
> that the goto statement is a denial of structure - since it can go
> anywhere, you can't make any assumptions about the program
> structure. The piece of code you're looking at can be mysteriously
> activated from somewhere else at any time. 

I am not sure I am "missing a point". Perhaps I have a different vision
of the computational process, hm? What is the "classical sense" for one
may be just an orthodox, restricted view for somebody from another galaxy.
I tend to apply often a Functionalist, sometimes too formal view on the
semantics of computations, you don't need to accept it, but I assure you
that for many people gotos *ARE* continuations. Continuation in a broad
sense is just the *specification* of what your <<future>> is.

Gotos and continuations may be as structured or as unstructured as the
programmers wishes, and the language permits. If all labels are static (no
jump address computed out of scratch), this is not true that a piece of code
can be "mysteriously activated" from "somewhere else", at "any" time. If,
in a disciplined and austere Scheme you permit yourself to plug into an 
*expression* (not even a "statement") the call-with-current-continuation
device, you may produce a bedlam which nobody understands, including the
author. This doesn't prove anything, but it suggests that your "classical
gotos" from the operational point of view are not restricted to classical
imperative code sequencing.

(Oh, I adored that wonderful piece of programming madness, an "article"
where somebody proposed a new super-Fortran where GO TO was replaced by
CAME FROM statement, and the language had an inspiring non-deterministic
conditional:   If <<condition>> THEN WHAT?.
Any references, anybody?)

> Continuations, on the other hand, have been discussed, and may
> very well wind up in Python some day. See the discussion around
> a variant called 'stackless.'

Yeah, I know it. I follow the Mission Impossible Software Team (Tismer
et al.) for some time. I am interested in scientific computing, and I 
believe that generators, coroutines etc. are essential for the simu-
lation. So, the idea to use continuations was for me always very
appealing (even if sometimes appalling...). Still, the notion of a
full continuation, as implicit in the letter of GvR
http://www.stackless.com/continuations.guido.van.rossum.html,
the machinery which makes a snapshot of the actual state, and which
is implemented in Scheme through call/cc, is not necessarily the
very essence of the concept itself, which is simpler. My turn to send
you to some references. I suggest the Andrew Appel's book 'Compiling
with Continuations'.


Thank you for this interesting exchange.

Jerzy Karczmarczuk
Caen, France