GOTO w/ Python?

[John Roth]

"Jerzy Karczmarczuk" <karczma at info.unicaen.fr> wrote in message
news:3D12EEAA.9C3A3D29 at info.unicaen.fr...
> 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.

Well, yes. My vision of what a GOTO is comes from my experiance in
the '60s, with early versions of Fortran, COBOL, various assemblers,
and so forth. This is what Dijkstra was talking about when he wrote
"GOTO considered harmful." It's completely unstructured. To put it
bluntly (because I can't think of a way to be more diplomatic this early
in the morning, sorry) attempting to redefine GOTO in terms of some
other structure misses the point completely: a major thread of
programming
language development since Dijkstra's letter has been to find language
structures that can do the job while eliminating the completely
unstructured
GOTO. Functional programming, continuations, structured exceptions,
and similar stuff are all attempts to provide structures that are
powerful
enough to get the job done, and structured enough that you can
reason about them.

To delve into the history of language development a bit: immediately
following Dijkstra, there was a minimalist structured programming
movement, and a horrible debate about the Case statement, and
similar constructs. The minimalists didn't want it, the people who
wanted to get the job done did.

> (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?)

It's been around for quite a while - I remember it from GUIDE meetings
in the '70s. There's a COBOL variant, and I'm certain there are others.
Once Dijkstra focused attention on the GOTO, someone came up
with COME FROM. It's actually very logical in a very warped way.
If the problem is that you can GOTO anywhere, leading to perplexity
as to how you got there, then why not have a construct that allows you
to say where you came from, thus removing the perplexity? I knew
people back then whose eyes glazed over considering it!

You might try the history of computing people -
although they might want this one to escape!

>
> Thank you for this interesting exchange.
>
> Jerzy Karczmarczuk
> Caen, France