Re: [Numpy-discussion] Python needs goto

[Anne Archibald]

goto! and comefrom! Together with exceptions, threads, lambda, super,
generators, and coroutines, all we're lacking is
call-with-current-continuation for the full list of impenetrable
control-flow constructs. Oh, and lisp-style resumable exception handling.
(Suggested syntax: drop(exception, value) to return control to where the
exception was raised and make the raise statement return value.)

On Thu, Sep 24, 2015 at 8:42 PM Charles R Harris 
wrote:

> On Thu, Sep 24, 2015 at 12:13 PM, Yarko Tymciurak 
> wrote:
>
>>
>>
>> I think there are more valid uses - I've read that "goto" basically is
>> what a state machine does.
>> Have a read of the brief implementation notes for "goto" in golang, for
>> example.  Goto may not be unreasonable to use, just most people would
>> abuse.  Sort of like "everyone shouldn't write assembly, but if you
>> understand the machine, you can make good things happen".  Without
>> compiler/interpreter checks, more responsibility rests on the coder to keep
>> out of trouble.
>>
>
> I would agree about state machines. When implemented using the standard
> control flow constructs they always look a bit artificial.
>
>
That depends what your "standard" control flow constructs are. Has anyone
tried implementing a state machine using coroutines? They seem like a
rather natural setup: each state is a coroutine that loops, doing the
appropriate actions for the state and then handing control over to the
coroutine for the next state.

Anne
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Python needs goto

[William Ray Wing]

> On Sep 25, 2015, at 1:53 AM, Alexander Eberspächer 
>  wrote:
> 
> On 24.09.2015 21:12, Charles R Harris wrote:
> 
>> I find Cleve Moler's old Fortran version of Brent's zero finding
>> algorithm using gotos clearer than the structured versions you can find
>> in Numerical Recipes. The operation of the algorithm is easiest to
>> describe as a finite state machine.
> 
> I need to look into that piece of Fortran code. I've never (knowingly)
> implemented a state-machine myself. However I can say that specifically
> Fortran has named loops, which probably helps to avoid many uses of goto.
> 

GOTOs really can be useful.  COMPUTED GOTOs, on the other hand, are a debugging 
nightmare, literally!!!

Bill


>> However, the post was for laughs, I didn't expect serious discussion.
> 
> Well, then let me fill in the missing piece - the obligatory XKCD strip:
> 
> https://www.xkcd.com/292/
> 
> Alex
> 
> 
> 
> 
> 
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> https://mail.scipy.org/mailman/listinfo/numpy-discussion

___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Python needs goto

[Christophe Bal]

Very funny !  
Le 25 sept. 2015 07:53, "Alexander Eberspächer" 
a écrit :

> On 24.09.2015 21:12, Charles R Harris wrote:
>
> > I find Cleve Moler's old Fortran version of Brent's zero finding
> > algorithm using gotos clearer than the structured versions you can find
> > in Numerical Recipes. The operation of the algorithm is easiest to
> > describe as a finite state machine.
>
> I need to look into that piece of Fortran code. I've never (knowingly)
> implemented a state-machine myself. However I can say that specifically
> Fortran has named loops, which probably helps to avoid many uses of goto.
>
> > However, the post was for laughs, I didn't expect serious discussion.
>
> Well, then let me fill in the missing piece - the obligatory XKCD strip:
>
> https://www.xkcd.com/292/
>
> Alex
>
>
>
>
>
>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> https://mail.scipy.org/mailman/listinfo/numpy-discussion
>
>
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Python needs goto

[Charles R Harris]

On Fri, Sep 25, 2015 at 10:27 AM, Anne Archibald 
wrote:

> goto! and comefrom! Together with exceptions, threads, lambda, super,
> generators, and coroutines, all we're lacking is
> call-with-current-continuation for the full list of impenetrable
> control-flow constructs. Oh, and lisp-style resumable exception handling.
> (Suggested syntax: drop(exception, value) to return control to where the
> exception was raised and make the raise statement return value.)
>
> On Thu, Sep 24, 2015 at 8:42 PM Charles R Harris <
> charlesr.har...@gmail.com> wrote:
>
>> On Thu, Sep 24, 2015 at 12:13 PM, Yarko Tymciurak 
>> wrote:
>>
>>>
>>>
>>> I think there are more valid uses - I've read that "goto" basically is
>>> what a state machine does.
>>> Have a read of the brief implementation notes for "goto" in golang, for
>>> example.  Goto may not be unreasonable to use, just most people would
>>> abuse.  Sort of like "everyone shouldn't write assembly, but if you
>>> understand the machine, you can make good things happen".  Without
>>> compiler/interpreter checks, more responsibility rests on the coder to keep
>>> out of trouble.
>>>
>>
>> I would agree about state machines. When implemented using the standard
>> control flow constructs they always look a bit artificial.
>>
>>
> That depends what your "standard" control flow constructs are. Has anyone
> tried implementing a state machine using coroutines? They seem like a
> rather natural setup: each state is a coroutine that loops, doing the
> appropriate actions for the state and then handing control over to the
> coroutine for the next state.
>
>
Might well do. TAOCP has an example elevator, passenger simulation that,
IIRC, used coroutines. I think I may have even once used a language that
had them (Algol 68?). It will be interesting to see what their inclusion in
Python 3.5 leads to.

Chuck
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Python needs goto

[Nathaniel Smith]

On Sep 25, 2015 11:06 AM, "Charles R Harris" 
wrote:
>
>
>
> On Fri, Sep 25, 2015 at 10:27 AM, Anne Archibald 
wrote:
>>
>> goto! and comefrom! Together with exceptions, threads, lambda, super,
generators, and coroutines, all we're lacking is
call-with-current-continuation for the full list of impenetrable
control-flow constructs. Oh, and lisp-style resumable exception handling.
(Suggested syntax: drop(exception, value) to return control to where the
exception was raised and make the raise statement return value.)
>>
>> On Thu, Sep 24, 2015 at 8:42 PM Charles R Harris <
charlesr.har...@gmail.com> wrote:
>>>
>>> On Thu, Sep 24, 2015 at 12:13 PM, Yarko Tymciurak 
wrote:



 I think there are more valid uses - I've read that "goto" basically is
what a state machine does.
 Have a read of the brief implementation notes for "goto" in golang,
for example.  Goto may not be unreasonable to use, just most people would
abuse.  Sort of like "everyone shouldn't write assembly, but if you
understand the machine, you can make good things happen".  Without
compiler/interpreter checks, more responsibility rests on the coder to keep
out of trouble.
>>>
>>>
>>> I would agree about state machines. When implemented using the standard
control flow constructs they always look a bit artificial.
>>>
>>
>> That depends what your "standard" control flow constructs are. Has
anyone tried implementing a state machine using coroutines? They seem like
a rather natural setup: each state is a coroutine that loops, doing the
appropriate actions for the state and then handing control over to the
coroutine for the next state.
>>
>
> Might well do. TAOCP has an example elevator, passenger simulation that,
IIRC, used coroutines. I think I may have even once used a language that
had them (Algol 68?). It will be interesting to see what their inclusion in
Python 3.5 leads to.

The coroutines in 3.5 are just syntactic sugar around features that were
added in *2*.5 (yield expressions and yield from), so no need to wait :-).
They fall far short of arbitrary continuations, though.

I don't think it's particularly cumbersome to implement a state machine
with one function per state and the return value specifying the new state
-- there's a little more typing to set up the local variables and such each
time, but if you have complex states then this seems like even an advantage
over goto (since with goto you may have to set up local state by hand each
time, basically reimplementing your own scoping mechanism). Of course if
all your states are trivial then this overhead is just annoying.

...I suspect you actually might be able to implement resumable exceptions
in cpython as a (very evil) third party module. I'm going to stop thinking
about that now before I get too curious and do something I regret.

Actually, don't stackless / greenlet give you full continuations?

-n
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Python needs goto

[Ryan May]

On Fri, Sep 25, 2015 at 3:02 PM, Nathaniel Smith  wrote:
>
> The coroutines in 3.5 are just syntactic sugar around features that were
> added in *2*.5 (yield expressions and yield from), so no need to wait :-).
> They fall far short of arbitrary continuations, though.
>

Correction: Python 3.4 gained "yield from". Prior to that, you had a lot of
work to properly delegate from one generator to another.

But yes, async and await are just syntactic sugar (consistent with other
languages) for python 3.4's coroutine functionality.

Ryan
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Python needs goto

[Benjamin Root]

Ow! Ow! Ow! I am just a meteorologist that has an obsession with looking up
unfamiliar technology terms.

I need a Tylenol...
Ben Root

On Fri, Sep 25, 2015 at 12:27 PM, Anne Archibald 
wrote:

> goto! and comefrom! Together with exceptions, threads, lambda, super,
> generators, and coroutines, all we're lacking is
> call-with-current-continuation for the full list of impenetrable
> control-flow constructs. Oh, and lisp-style resumable exception handling.
> (Suggested syntax: drop(exception, value) to return control to where the
> exception was raised and make the raise statement return value.)
>
> On Thu, Sep 24, 2015 at 8:42 PM Charles R Harris <
> charlesr.har...@gmail.com> wrote:
>
>> On Thu, Sep 24, 2015 at 12:13 PM, Yarko Tymciurak 
>> wrote:
>>
>>>
>>>
>>> I think there are more valid uses - I've read that "goto" basically is
>>> what a state machine does.
>>> Have a read of the brief implementation notes for "goto" in golang, for
>>> example.  Goto may not be unreasonable to use, just most people would
>>> abuse.  Sort of like "everyone shouldn't write assembly, but if you
>>> understand the machine, you can make good things happen".  Without
>>> compiler/interpreter checks, more responsibility rests on the coder to keep
>>> out of trouble.
>>>
>>
>> I would agree about state machines. When implemented using the standard
>> control flow constructs they always look a bit artificial.
>>
>>
> That depends what your "standard" control flow constructs are. Has anyone
> tried implementing a state machine using coroutines? They seem like a
> rather natural setup: each state is a coroutine that loops, doing the
> appropriate actions for the state and then handing control over to the
> coroutine for the next state.
>
> Anne
>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> https://mail.scipy.org/mailman/listinfo/numpy-discussion
>
>
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Python needs goto

[Nathaniel Smith]

On Fri, Sep 25, 2015 at 2:39 PM, Ryan May  wrote:
>
> On Fri, Sep 25, 2015 at 3:02 PM, Nathaniel Smith  wrote:
>>
>> The coroutines in 3.5 are just syntactic sugar around features that were
>> added in *2*.5 (yield expressions and yield from), so no need to wait :-).
>> They fall far short of arbitrary continuations, though.
>
>
> Correction: Python 3.4 gained "yield from". Prior to that, you had a lot of
> work to properly delegate from one generator to another.

Ah, right, thanks for the correction. Not sure how much yield from
matters for state machines, but certainly it's great for async IO.

-n

-- 
Nathaniel J. Smith -- http://vorpus.org
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Python needs goto

[Christophe Bal]

Hello.

Can you give an example where GOTO is useful ?
Le 24 sept. 2015 07:24, "Charles R Harris"  a
écrit :

> At last, goto for python !
>
> Usage:
>
> from goto import with_goto
>
> @with_goto
> def range(start, stop):
> i = start
> result = []
>
> label .begin
> if i == stop:
> goto .end
>
> result.append(i)
> i += 1
> goto .begin
>
> label .end
> return result
>
>
> HT: LWN
>
> Chuck
>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> https://mail.scipy.org/mailman/listinfo/numpy-discussion
>
>
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Python needs goto

[R Schumacher]

An older non-decorator implementation, with examples (slower)
http://entrian.com/goto/


At 04:25 AM 9/24/2015, you wrote:


Hello.

Can you give an example where GOTO is useful ?
Le 24 sept. 2015 07:24, "Charles R Harris" 
<charlesr.har...@gmail.com> a écrit :

At last, goto for python!

Usage:
from goto import with_goto


@with_goto

def range(start, stop):

i = start

result = []


label .begin

if i == stop:

goto .end


result.append(i)

i += 1

goto .begin


label .end

return result

HT: LWN

Chuck

___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Python needs goto

[Christophe Bal]

To be honest, I am not very conviced. Does someone can give a pseudo
example ?
Le 24 sept. 2015 20:50, "Benjamin Root"  a écrit :

> Most of the time when I wanted to use goto in my early days, I found that
> breaks and continues were better and easier to understand. I will admit
> that there are occasional nested if/elif/else code that get messy without a
> goto. But which smells worse? A "goto" package or a complex if/elif/else?
>
> Ben Root
>
> On Thu, Sep 24, 2015 at 2:41 PM, Charles R Harris <
> charlesr.har...@gmail.com> wrote:
>
>>
>>
>> On Thu, Sep 24, 2015 at 12:13 PM, Yarko Tymciurak 
>> wrote:
>>
>>>
>>>
>>> On Thu, Sep 24, 2015 at 12:54 PM, Alexander Eberspächer <
>>> alex.eberspaec...@gmail.com> wrote:
>>>
 On 24.09.2015 13:25, Christophe Bal wrote:

 > Can you give an example where GOTO is useful ?

 I think those pieces of code are best understood with some humour..

 However, basically I can think two main causes for using goto:

 1. Stop whatever your code is doing and jump towards the end of the
 program. However, this is mainly something useful for languages without
 exception handling and garbage collection.

 2. Get out of something deeply nested. Also, this probably isn't very
 useful in Python as there's exception handling.

>>>
>>> I think there are more valid uses - I've read that "goto" basically is
>>> what a state machine does.
>>> Have a read of the brief implementation notes for "goto" in golang, for
>>> example.  Goto may not be unreasonable to use, just most people would
>>> abuse.  Sort of like "everyone shouldn't write assembly, but if you
>>> understand the machine, you can make good things happen".  Without
>>> compiler/interpreter checks, more responsibility rests on the coder to keep
>>> out of trouble.
>>>
>>
>> I would agree about state machines. When implemented using the standard
>> control flow constructs they always look a bit artificial.
>>
>> Chuck
>>
>>
>> ___
>> NumPy-Discussion mailing list
>> NumPy-Discussion@scipy.org
>> https://mail.scipy.org/mailman/listinfo/numpy-discussion
>>
>>
>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> https://mail.scipy.org/mailman/listinfo/numpy-discussion
>
>
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Python needs goto

[Charles R Harris]

On Thu, Sep 24, 2015 at 12:57 PM, Christophe Bal 
wrote:

> By pseudo example, I mean pseudo code.
>

I find Cleve Moler's old Fortran version of Brent's zero finding algorithm
using gotos clearer than the structured versions you can find in Numerical
Recipes. The operation of the algorithm is easiest to describe as a finite
state machine. As others have said, goto is also useful for languages
without exception handling, C for instance. You will find gotos in the
Linux kernel and in the Numpy core used for that purpose.

However, the post was for laughs, I didn't expect serious discussion. The
current thread is a pleasant surprise.

Chuck
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Python needs goto

[Charles R Harris]

On Thu, Sep 24, 2015 at 12:13 PM, Yarko Tymciurak  wrote:

>
>
> On Thu, Sep 24, 2015 at 12:54 PM, Alexander Eberspächer <
> alex.eberspaec...@gmail.com> wrote:
>
>> On 24.09.2015 13:25, Christophe Bal wrote:
>>
>> > Can you give an example where GOTO is useful ?
>>
>> I think those pieces of code are best understood with some humour..
>>
>> However, basically I can think two main causes for using goto:
>>
>> 1. Stop whatever your code is doing and jump towards the end of the
>> program. However, this is mainly something useful for languages without
>> exception handling and garbage collection.
>>
>> 2. Get out of something deeply nested. Also, this probably isn't very
>> useful in Python as there's exception handling.
>>
>
> I think there are more valid uses - I've read that "goto" basically is
> what a state machine does.
> Have a read of the brief implementation notes for "goto" in golang, for
> example.  Goto may not be unreasonable to use, just most people would
> abuse.  Sort of like "everyone shouldn't write assembly, but if you
> understand the machine, you can make good things happen".  Without
> compiler/interpreter checks, more responsibility rests on the coder to keep
> out of trouble.
>

I would agree about state machines. When implemented using the standard
control flow constructs they always look a bit artificial.

Chuck
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Python needs goto

[Christophe Bal]

By pseudo example, I mean pseudo code.
Le 24 sept. 2015 20:56, "Christophe Bal"  a écrit :

> To be honest, I am not very conviced. Does someone can give a pseudo
> example ?
> Le 24 sept. 2015 20:50, "Benjamin Root"  a écrit :
>
>> Most of the time when I wanted to use goto in my early days, I found that
>> breaks and continues were better and easier to understand. I will admit
>> that there are occasional nested if/elif/else code that get messy without a
>> goto. But which smells worse? A "goto" package or a complex if/elif/else?
>>
>> Ben Root
>>
>> On Thu, Sep 24, 2015 at 2:41 PM, Charles R Harris <
>> charlesr.har...@gmail.com> wrote:
>>
>>>
>>>
>>> On Thu, Sep 24, 2015 at 12:13 PM, Yarko Tymciurak 
>>> wrote:
>>>


 On Thu, Sep 24, 2015 at 12:54 PM, Alexander Eberspächer <
 alex.eberspaec...@gmail.com> wrote:

> On 24.09.2015 13:25, Christophe Bal wrote:
>
> > Can you give an example where GOTO is useful ?
>
> I think those pieces of code are best understood with some humour..
>
> However, basically I can think two main causes for using goto:
>
> 1. Stop whatever your code is doing and jump towards the end of the
> program. However, this is mainly something useful for languages without
> exception handling and garbage collection.
>
> 2. Get out of something deeply nested. Also, this probably isn't very
> useful in Python as there's exception handling.
>

 I think there are more valid uses - I've read that "goto" basically is
 what a state machine does.
 Have a read of the brief implementation notes for "goto" in golang, for
 example.  Goto may not be unreasonable to use, just most people would
 abuse.  Sort of like "everyone shouldn't write assembly, but if you
 understand the machine, you can make good things happen".  Without
 compiler/interpreter checks, more responsibility rests on the coder to keep
 out of trouble.

>>>
>>> I would agree about state machines. When implemented using the standard
>>> control flow constructs they always look a bit artificial.
>>>
>>> Chuck
>>>
>>>
>>> ___
>>> NumPy-Discussion mailing list
>>> NumPy-Discussion@scipy.org
>>> https://mail.scipy.org/mailman/listinfo/numpy-discussion
>>>
>>>
>>
>> ___
>> NumPy-Discussion mailing list
>> NumPy-Discussion@scipy.org
>> https://mail.scipy.org/mailman/listinfo/numpy-discussion
>>
>>
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Python needs goto

[Yarko Tymciurak]

On Thu, Sep 24, 2015 at 12:54 PM, Alexander Eberspächer <
alex.eberspaec...@gmail.com> wrote:

> On 24.09.2015 13:25, Christophe Bal wrote:
>
> > Can you give an example where GOTO is useful ?
>
> I think those pieces of code are best understood with some humour..
>
> However, basically I can think two main causes for using goto:
>
> 1. Stop whatever your code is doing and jump towards the end of the
> program. However, this is mainly something useful for languages without
> exception handling and garbage collection.
>
> 2. Get out of something deeply nested. Also, this probably isn't very
> useful in Python as there's exception handling.
>

I think there are more valid uses - I've read that "goto" basically is what
a state machine does.
Have a read of the brief implementation notes for "goto" in golang, for
example.  Goto may not be unreasonable to use, just most people would
abuse.  Sort of like "everyone shouldn't write assembly, but if you
understand the machine, you can make good things happen".  Without
compiler/interpreter checks, more responsibility rests on the coder to keep
out of trouble.



>
> Best
>
> Alex
>
>
>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> https://mail.scipy.org/mailman/listinfo/numpy-discussion
>
>
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Python needs goto

[Jason Newton]

In my experience, it's also come up with finite-state-machines where
there's lots of loops.  You might consider something like a long-lived
client-loop on some socket, where states like try-connect, connected, and
while-connected-and-everythings-ok exist and each can have it's own never
ending loops and each loop jumps to each others section.  It actually is
more straightforward than adding unneeded layers like callbacks which will
force you to design and pass around data, use auxiliary classes/structs,
and it's easier to shoot yourself in the foot with burden and context loss
that way.

-Jason

On Thu, Sep 24, 2015 at 1:54 PM, Alexander Eberspächer <
alex.eberspaec...@gmail.com> wrote:

> On 24.09.2015 13:25, Christophe Bal wrote:
>
> > Can you give an example where GOTO is useful ?
>
> I think those pieces of code are best understood with some humour..
>
> However, basically I can think two main causes for using goto:
>
> 1. Stop whatever your code is doing and jump towards the end of the
> program. However, this is mainly something useful for languages without
> exception handling and garbage collection.
>
> 2. Get out of something deeply nested. Also, this probably isn't very
> useful in Python as there's exception handling.
>
> Best
>
> Alex
>
>
>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> https://mail.scipy.org/mailman/listinfo/numpy-discussion
>
>
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Python needs goto

[Alexander Eberspächer]

On 24.09.2015 13:25, Christophe Bal wrote:

> Can you give an example where GOTO is useful ?

I think those pieces of code are best understood with some humour..

However, basically I can think two main causes for using goto:

1. Stop whatever your code is doing and jump towards the end of the
program. However, this is mainly something useful for languages without
exception handling and garbage collection.

2. Get out of something deeply nested. Also, this probably isn't very
useful in Python as there's exception handling.

Best

Alex




signature.asc
Description: OpenPGP digital signature
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Python needs goto

[Benjamin Root]

Most of the time when I wanted to use goto in my early days, I found that
breaks and continues were better and easier to understand. I will admit
that there are occasional nested if/elif/else code that get messy without a
goto. But which smells worse? A "goto" package or a complex if/elif/else?

Ben Root

On Thu, Sep 24, 2015 at 2:41 PM, Charles R Harris  wrote:

>
>
> On Thu, Sep 24, 2015 at 12:13 PM, Yarko Tymciurak 
> wrote:
>
>>
>>
>> On Thu, Sep 24, 2015 at 12:54 PM, Alexander Eberspächer <
>> alex.eberspaec...@gmail.com> wrote:
>>
>>> On 24.09.2015 13:25, Christophe Bal wrote:
>>>
>>> > Can you give an example where GOTO is useful ?
>>>
>>> I think those pieces of code are best understood with some humour..
>>>
>>> However, basically I can think two main causes for using goto:
>>>
>>> 1. Stop whatever your code is doing and jump towards the end of the
>>> program. However, this is mainly something useful for languages without
>>> exception handling and garbage collection.
>>>
>>> 2. Get out of something deeply nested. Also, this probably isn't very
>>> useful in Python as there's exception handling.
>>>
>>
>> I think there are more valid uses - I've read that "goto" basically is
>> what a state machine does.
>> Have a read of the brief implementation notes for "goto" in golang, for
>> example.  Goto may not be unreasonable to use, just most people would
>> abuse.  Sort of like "everyone shouldn't write assembly, but if you
>> understand the machine, you can make good things happen".  Without
>> compiler/interpreter checks, more responsibility rests on the coder to keep
>> out of trouble.
>>
>
> I would agree about state machines. When implemented using the standard
> control flow constructs they always look a bit artificial.
>
> Chuck
>
>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> https://mail.scipy.org/mailman/listinfo/numpy-discussion
>
>
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Python needs goto

[Alexander Eberspächer]

On 24.09.2015 21:12, Charles R Harris wrote:

> I find Cleve Moler's old Fortran version of Brent's zero finding
> algorithm using gotos clearer than the structured versions you can find
> in Numerical Recipes. The operation of the algorithm is easiest to
> describe as a finite state machine.

I need to look into that piece of Fortran code. I've never (knowingly)
implemented a state-machine myself. However I can say that specifically
Fortran has named loops, which probably helps to avoid many uses of goto.

> However, the post was for laughs, I didn't expect serious discussion.

Well, then let me fill in the missing piece - the obligatory XKCD strip:

https://www.xkcd.com/292/

Alex







signature.asc
Description: OpenPGP digital signature
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] Python needs goto

[Charles R Harris]

At last, goto for python !

Usage:

from goto import with_goto

@with_goto
def range(start, stop):
i = start
result = []

label .begin
if i == stop:
goto .end

result.append(i)
i += 1
goto .begin

label .end
return result


HT: LWN

Chuck
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion