GOTO w/ Python?
John Roth
"Angela Williams" <adwill...@hotmail.com> wrote in message
news:3d10ed95@xpl-sdf1-sec1....
> I'm looking for the equivalent of the GOTO command for Python 2.2.1
running
> on Windows 98. I have programmed very little and am new to Python. I
found
> the following information on the FAQ page but it doesn't make any
sense to
> me.
>
>
> 6.26. Why no goto?
> Actually, you can use exceptions to provide a "structured goto" that
even
> works across function calls. Many feel that exceptions can
conveniently
> emulate all reasonable uses of the "go" or "goto" constructs of C,
Fortran,
> and other languages. For example:
>
> class label: pass # declare a label
> try:
> ...
> if (condition): raise label() # goto label
> ...
> except label: # where to goto
> pass
> ...
>
> This doesn't allow you to jump into the middle of a loop, but that's
usually
> considered an abuse of goto anyway. Use sparingly.
>
>
>
> Any and all help would be greatly appreciated.
>
> Thanks, Angela
There's no equivalent of a goto command in Python, for good reason,
which I won't repeat here. Prof. Djikstra did it very well in 1974,
in his letter "Goto Considered Harmful."
If you'd like to post the problem you're trying to solve, someone
will be sure to help you.
The reason for mentioning exceptions in the FAQ is that, for a
long while, exception handling was the sole programming task
where people thought they still needed a goto. That was solved
over a decade ago, with structured exception handling, and Python
simply does it the same as everyone else, only (possibly) better.
John Roth
>
>
Fredrik Lundh
> I'm looking for the equivalent of the GOTO command for Python 2.2.1 running
> on Windows 98. I have programmed very little and am new to Python.
like most modern programming languages, Python doesn't have
a GOTO command. for a brief explanation of why, and what you
should use instead, check the "branching" chapter in Alan Gauld's
"Learning to Program" tutorial:
http://www.freenetpages.co.uk/hp/alan.gauld/
(if you're new to programming, I suggest working through the
entire tutorial)
you can find more Python tutorials here:
http://www.python.org/doc/Newbies.html
</F>
Fernando Pérez
>
> you can find more Python tutorials here:
>
> http://www.python.org/doc/Newbies.html
>
I've always been curious. Why isn't the standard tutorial linked to here? It
seems like the obvious first link to have, no?
Cheers,
f
Gerhard Häring
Because it's not well suited for _programming_ newbies? It's, however,
good material if you already know to program.
Gerhard
--
mail: gerhard <at> bigfoot <dot> de registered Linux user #64239
web: http://www.cs.fhm.edu/~ifw00065/ OpenPGP public key id AD24C930
public key fingerprint: 3FCC 8700 3012 0A9E B0C9 3667 814B 9CAA AD24 C930
reduce(lambda x,y:x+y,map(lambda x:chr(ord(x)^42),tuple('zS^BED\nX_FOY\x0b')))
Fernando Pérez
>> I've always been curious. Why isn't the standard tutorial linked to here?
>> It seems like the obvious first link to have, no?
>
> Because it's not well suited for programming newbies?
Mmmhh, I'd disagree with that. Considering that it introduces all the data
types and control structures one by one, nicely and slowly, I'd imagine many
programming newbies could actually pick it up fairly well. Granted, by the
time I read it I had been programming for many years and python was like my
10th language, so I have a hard time judging it from a 'programming newbie'
perspective. But I honestly think it's clear and slow-paced enough to be a
good starting point for any newbie.
It could perhaps be included there with a simple comment like 'This tutorial
may be a bit difficult to follow if you have zero previous programming
experience in other languages. But if you know the basic concepts of computer
programming, it will get you up to speed in python in half an afternoon.'
Cheers,
f.
Michael Hudson
> There's no equivalent of a goto command in Python, for good reason,
> which I won't repeat here. Prof. Djikstra did it very well in 1974,
> in his letter "Goto Considered Harmful."
There are also technical difficulties implementing it (the
blockstack), or I'd have probably done goto functionality in
bytecodehacks :)
Cheers,
M.
--
The ability to quote is a serviceable substitute for wit.
-- W. Somerset Maugham
Simon Brunning
> There's no equivalent of a goto command in Python, for good reason,
> which I won't repeat here. Prof. Djikstra did it very well in 1974,
> in his letter "Goto Considered Harmful."
Cheers,
Simon Brunning
TriSystems Ltd.
sbru...@trisystems.co.uk
-----------------------------------------------------------------------
The information in this email is confidential and may be legally privileged.
It is intended solely for the addressee. Access to this email by anyone else
is unauthorised. If you are not the intended recipient, any disclosure,
copying, distribution, or any action taken or omitted to be taken in
reliance on it, is prohibited and may be unlawful. TriSystems Ltd. cannot
accept liability for statements made which are clearly the senders own.
Max M
> "John Roth" <john...@ameritech.net> writes:
>
>
>>There's no equivalent of a goto command in Python, for good reason,
>>which I won't repeat here. Prof. Djikstra did it very well in 1974,
>>in his letter "Goto Considered Harmful."
>
>
> There are also technical difficulties implementing it (the
> blockstack), or I'd have probably done goto functionality in
> bytecodehacks :)
What do you mean???
Goto's are simple ;-)
def goto(lable):
lable()
def start():
print 'starting'
goto(lable2)
def lable1():
print 'at lable 1'
goto(stop)
def lable2():
print 'at lable 2'
goto(lable1)
def stop():
print 'stopping'
goto(start)
>>> starting
>>> at lable 2
>>> at lable 1
>>> stopping
John Roth
"Max M" <ma...@mxm.dk> wrote in message news:3D11A21D...@mxm.dk...
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!
John Roth
>
Jerzy Karczmarczuk
> > 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,
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.
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.
Jerzy Karczmarczuk
Caen, France
John Roth
"Jerzy Karczmarczuk" <kar...@info.unicaen.fr> wrote in message
news:3D11DA9B...@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
Martijn Faassen
[snip]
> There's no equivalent of a goto command in Python, for good reason,
> which I won't repeat here. Prof. Djikstra did it very well in 1974,
> in his letter "Goto Considered Harmful."
The good old Djikstra! You know, some years ago in another newsgroup I saw
so many posts referring to some computer scientist called 'Djikstra', I
started to doubt myself and had to confirm that he really is called
'Dijkstra'.
Now I realize that there is a Djikstra, and a Dijkstra as well. Djikstra
is an evil clone of Dijkstra, which the Python Secret Underground is
keeping on ice in case they need any evil clones.
Regards,
'Martjin'
--
History of the 20th Century: WW1, WW2, WW3?
No, WWW -- Could we be going in the right direction?
John Roth
"Martijn Faassen" <m.fa...@vet.uu.nl> wrote in message
news:aetbqv$kgq$1...@newshost.accu.uu.nl...
> John Roth <john...@ameritech.net> wrote:
> [snip]
> > There's no equivalent of a goto command in Python, for good reason,
> > which I won't repeat here. Prof. Djikstra did it very well in 1974,
> > in his letter "Goto Considered Harmful."
>
> The good old Djikstra! You know, some years ago in another newsgroup I
saw
> so many posts referring to some computer scientist called 'Djikstra',
I
> started to doubt myself and had to confirm that he really is called
> 'Dijkstra'.
>
> Now I realize that there is a Djikstra, and a Dijkstra as well.
Djikstra
> is an evil clone of Dijkstra, which the Python Secret Underground is
> keeping on ice in case they need any evil clones.
Given the Professor's reputation as somewhat of a
curmudgeon, wouldn't that be an identity function?
Sorry about the misspelling.
John Roth
Martijn Faassen
[snip Djikstra being an evil clone of Dijkstra]
> Given the Professor's reputation as somewhat of a
> curmudgeon, wouldn't that be an identity function?
It's a possibility. Did you know Dijkstra originated in the
Netherlands but now lives in the US, just like Guido? Not implying
in any way that Guido is somewhat of a curmudgeon. :)
> Sorry about the misspelling.
I was just amused, not upset.
I can see where a non-Dutch speaker's brain would say 'Dijkstra' has *five*
consonants in a row, that can't be real, I'll make it 'Djikstra' instead.
But, in Dutch 'ij' is actually a vowel sound. My name for instance is
pronounced approximately like 'Mar-tine', where 'tine' rhymes with 'line'
and such. But only approximately.
Of course Guido has a hard Dutch 'g' in his name, the most horrible
'throat disease' sound in the Dutch language according to many foreigners
('ch' is another variety of our hard 'g' which may even be worse, though
'sch' also probably ranks highly). However, I grew up in
the south of the Netherlands and the accents there employ a much softer
'g', so I don't even pronounce Guido's name in the way he does.
Anyway, did you know that Dutch is the official natural language for
Python programmers? It's true! Here is some of the evidence:
http://groups.google.com/groups?hl=en&lr=&th=8fc168631bc6097a
(follow the thread)
Regards,
Martijn
Delaney, Timothy
> >
> > Goto's are simple ;-)
[Clever, silly, not real GOTO example snipped]
> 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!
Methinks someone missed something ...
Tim Delaney
Donn Cave
...
| 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.
The stackless branch of python supported a very rich set of
continuation options. I use the past tense, because it seems
to have been a little too powerful for even the mainly feature
hungry python crowd, so current development of stackless has
dropped most of that stuff. I hope we're talking about the same
thing - these continuations suspend and resume computations like
a kind of serialized multi-threading.
For me, genuine gotos are only a matter of flow control along the
same lines as "while" loops. Internal to a computation, if you
will - one doesn't goto out of or into a procedure. I think in
some sense of "ideal", an ideal procedural language would have goto,
because it expresses some problems most directly and the need to
emulate it with "while" or "try" makes worse code. The branching
in a goto construct is perfectly apparent, it just can be harder
to get an overall sense of the flow if goto is over-used. Why,
even our beloved python itself had a few judiciously used gotos
last time I looked.
Continuations I'm not so sure about. I wrote some stackless stuff
that made really interesting (to me, anyway) use of them, but now
we're talking about flow of control that really is easy to misunderstand.
| 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.
If Michael Hudson says there are technical difficulties, I would
take that as fact, but a fact about Python's current internals.
If goto had been wanted, I'm sure Python's design could have
accommodated it.
Donn Cave, do...@drizzle.com
Jerzy Karczmarczuk
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
Christian Tismer
> John Roth comments my observation concerning the relation between gotos
> and continuations:
...
>>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.'
Guys, I'm watching you! :-)
> 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'.
In fact, Guido isn't correct with copying the full execution
stack. The continuations implementation which I did is completely
different in that sense and tries to copy the minimum necessary
to survive.
Appel's book can really be recommended if you like to learn
a new way of thinking.
Still, I'm not planning to support full continuations again.
The immutability of continuations is a hard requirement,
and I didn't find an application yet where mutable tasklets
didn't suffice.
ciao - chris
--
Christian Tismer :^) <mailto:tis...@tismer.com>
Mission Impossible 5oftware : Have a break! Take a ride on Python's
Johannes-Niemeyer-Weg 9a : *Starship* http://starship.python.net/
14109 Berlin : PGP key -> http://wwwkeys.pgp.net/
work +49 30 89 09 53 34 home +49 30 802 86 56 pager +49 173 24 18 776
PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04
whom do you want to sponsor today? http://www.stackless.com/
John Roth
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!
Robert Amesz
> I'm looking for the equivalent of the GOTO command for Python
> 2.2.1 running on Windows 98. I have programmed very little and am
> new to Python. I found the following information on the FAQ page
> but it doesn't make any sense to me.
Pleas don't go looking for GOTOs. If you find yourself needing those,
in 99.9% of the cases there's something not quite right with your code.
Usually, by splitting a large function/method into several smaller ones
the problem will go away by itself. The resulting code will also be
clearer and more maintainable.
(If after that you're still having trouble, post a page or so of your
code here. This is a helpful group, and I'm sure somebody will give you
some points on how to improve your code.)
The most goto-like contructs in Python are 'return' (which exits from a
function/method before the end is reached) and 'break' (which exits a
loop, continuing with statement followin that loop).
In a pinch you can indeed raise some kind of exception, but you really
should use those for things like errors.
Robert Amesz
Gerhard Häring
> The most goto-like contructs in Python are 'return' (which exits from a
> function/method before the end is reached) and 'break' (which exits a
> loop, continuing with statement followin that loop).
And 'continue', which immediately goes to the beginning of the loop.
Speaking of which, unlike in some other languages, 'break' and 'continue'
cannot be used with named loops, so you need exceptions in this case.
Gerhard
--
mail: gerhard <at> bigfoot <dot> de registered Linux user #64239
web: http://www.cs.fhm.edu/~ifw00065/ OpenPGP public key id 86AB43C0
public key fingerprint: DEC1 1D02 5743 1159 CD20 A4B6 7B22 6575 86AB 43C0
Carl Banks
> 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.
Perl was also designed late 80's, early 90's, but it does have goto in
it. I doubt Larry Wall was ever laughed out of a room.
Then again, one of the Perl manpages presents this as an "interesting
approach to a switch statement":
$amode = do {
if ($flag & O_RDONLY) { "r" } # XXX: isn't this 0?
elsif ($flag & O_WRONLY) { ($flag & O_APPEND) ? "a" : "w" }
elsif ($flag & O_RDWR) {
if ($flag & O_CREAT) { "w+" }
else { ($flag & O_APPEND) ? "a+" : "r+" }
}
};
So maybe these people thought goto was a little boring.
:)
--
CARL BANKS http://www.aerojockey.com
"Nullum mihi placet tamquam provocatio magna. Hoc ex eis non est."
Carl Banks
> (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?)
http://www.fortran.com/fortran/come_from.html
Daniel Fackrell
it conceptually different from short procedures? Does the only difference
lie in the fact that for compiled languages one of the instances will be
inline? I do understand that it would have some effect on variable scoping,
but this can be easily handled in other ways.
So what's the benefit that might outweigh the opacity of the code created?
--
Daniel Fackrell (dfac...@linuxmail.org)
When we attempt the impossible, we can experience true growth.
"Carl Banks" <imb...@vt.edu> wrote in message
news:6v30fa...@grey.aerojockey.localdomain...
Delaney, Timothy
>
> After skimming the linked page to get a feel for the CAME
> FROM statement, is
> it conceptually different from short procedures? Does the
> only difference
> lie in the fact that for compiled languages one of the
> instances will be
> inline? I do understand that it would have some effect on
> variable scoping,
> but this can be easily handled in other ways.
>
> So what's the benefit that might outweigh the opacity of the
> code created?
I hope you're not serious ... :)
COME FROM is a joke. Literally. It is a parody of GOTO whose only redeeming
feature is that it is not GOTO.
Tim Delaney
John Roth
"Daniel Fackrell" <dfac...@DELETETHIS.linuxmail.org> wrote in message
news:3d1730f2$1...@hpb10302.boi.hp.com...
> After skimming the linked page to get a feel for the CAME FROM
statement, is
> it conceptually different from short procedures? Does the only
difference
> lie in the fact that for compiled languages one of the instances will
be
> inline? I do understand that it would have some effect on variable
scoping,
> but this can be easily handled in other ways.
>
> So what's the benefit that might outweigh the opacity of the code
created?
It's a joke! Really.
John Roth
Daniel Fackrell
news:mailman.1024964672...@python.org...
*WHOOSH*
I missed that one completely. Maybe I'm trying too hard.
I was actually trying to figure out any possible reason that one would want
to use such a construct. I got thinking about compiler-level optimizations,
but the overhead involved would outweigh any possible savings in time or
compiled code size in almost all cases.
Thanks for straightening me out.
Emile van Sebille
> I hope you're not serious ... :)
>
> COME FROM is a joke. Literally. It is a parody of GOTO whose only
redeeming
> feature is that it is not GOTO.
>
Having programmed extensively using GOTOs, I'll say the redeeming
feature of _COME FROM_ is that it makes GOTO look good! ;-)
So-much-spaghetti-so-little-space-ly y'rs,
--
Emile van Sebille
em...@fenx.com
---------
Andrew Koenig
Tim> redeeming feature is that it is not GOTO.
The "Come From" statement sucks. Literally.
--
Andrew Koenig, a...@research.att.com, http://www.research.att.com/info/ark