GOTO w/ Python?

[John Roth]

"Jerzy Karczmarczuk" <karczma at info.unicaen.fr> wrote in message
news:3D11DA9B.163A7BD0 at info.unicaen.fr...
> John Roth after Michael Hudson after Max M.:
>
> > > Goto's are simple ;-)
> > > def goto(lable):
> > >      lable()
> > > def start():
> > >
> > >      print 'starting'
> > >      goto(lable2)
> > >
> > > def lable1():
> > >
> > >      print 'at lable 1'
> > >      goto(stop)
>
> etc.
>
> > Those aren't goto's in the classical sense. For a real goto,
> > you need to think assembler: if it's a statement anywhere,
> > you can branch to it, and who cares about the execution
> > history! Having the compiler manage your flow control is
> > for sissys!
>
> Gentlemen, what are you talking about?
> (I confess I didn't follow this thread, so forgive me if I
> try to open a non-existent door)
>
> Before, John Roth suggested using structured exceptions as GOTOs,

Nope. I did no such thing. I pointed out that structured
exceptions were what drove the last goto's out of more
modern languages. Structured programming is what got
rid of most of them.

> and Michael Hudson wrote something like that:
>
> > There are also technical difficulties implementing it (the
> > blockstack), or I'd have probably done goto functionality in
> > bytecodehacks :)
>
>
> Well...
>
> 1. The "solution" of Max M. is erroneous for two reasons.
>    A. A procedure call stacks the return address, so a few hundreds
>       such gotos, and the system blows up.
>       Unfortunately Python does not optimize tail calls, I WONDER WHY;
>       for a member of the Functional Programming Church this is
>       a mortal sin, and I am serious.
>    B. The code chunks linked in such a way provide different variable
>       scopes, so there is little sense in calling it a "branching".
>
> 2. "Structured exception" is something quite heavy, it may be heavier
>    than the setjump/longjump contraption, and may also be useless to
>    those who simply would love to do some Python programming à la
>    Fortran.
>
> 3. No, 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. The technique is called
"spaghetti coding," and is not recommended by anyone sane (except
for job security, of course.)

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.'

>    I don't believe that there are any technical difficulties in the
>    implementation of gotos at the low level. At the high level this
>    is then a question of the language structure, as seen by Van
Rossum,
>    the lack of gotos was a conscious decision.

At the time he designed the language, I suspect that if anyone had
brought it up, he'd have been laughed out of the room. We're talking
late 80's, early 90s here, not the '60s or '70s.

John Roth
>
>
> Jerzy Karczmarczuk
> Caen, France