Re: Goto

[John Wong]

I think the point is there is not much to discuss. Goto is not going to be
added. Furthermore, for every program language you want to translate from
source, you have to find a workaround. Otherwise, your translation will
only work for languages that have goto. Even so the implementation may not
be exact what C goto is. Who knows. Much like in Go - the other day, slice
there has a different behavior to Python’s slice. I brought this up to show
that don’t expect everything to be equal.

John

On Tue, Jan 2, 2018 at 12:35 bartc  wrote:

> On 02/01/2018 15:20, Chris Angelico wrote:
> > On Wed, Jan 3, 2018 at 1:51 AM, bartc  wrote:
>
> >> I like to write code in a simple, clean, universal style that everyone
> can
> >> understand.
> >>
> >> That doesn't mean it has to look like Fortran.
> >
> > Why are you using a Python interpreter then? Why are you here on
> > python-list, talking about Python? There must be SOME reason for using
> > this language rather than another.
>
> I'm more familiar with Python than any other like languages.
>
> If I desperately needed a dynamic language and I couldn't use my own,
> then I would use Python.
>
> But I would need to use it on my own terms, regardless of whether the
> result is 'pythonic'. If the language had 'goto', then I would use it if
> I found it apt.
>
> However, the discussion here is academic, so it doesn't matter who uses
> what.
>
> Apart from anything else, Python is never going to officially adopt
> 'goto'. (Regardless of some version of it being available as an add-on
> library. Most things seem to be.)
>
>
> --
> bartc
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
Sent from Jeff Dean's printf() mobile console
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Goto

[bartc]

On 02/01/2018 15:20, Chris Angelico wrote:

On Wed, Jan 3, 2018 at 1:51 AM, bartc  wrote:



I like to write code in a simple, clean, universal style that everyone can
understand.

That doesn't mean it has to look like Fortran.


Why are you using a Python interpreter then? Why are you here on
python-list, talking about Python? There must be SOME reason for using
this language rather than another.


I'm more familiar with Python than any other like languages.

If I desperately needed a dynamic language and I couldn't use my own, 
then I would use Python.


But I would need to use it on my own terms, regardless of whether the 
result is 'pythonic'. If the language had 'goto', then I would use it if 
I found it apt.


However, the discussion here is academic, so it doesn't matter who uses 
what.


Apart from anything else, Python is never going to officially adopt 
'goto'. (Regardless of some version of it being available as an add-on 
library. Most things seem to be.)



--
bartc
--
https://mail.python.org/mailman/listinfo/python-list

Re: Goto

[Chris Angelico]

On Wed, Jan 3, 2018 at 1:51 AM, bartc  wrote:
> On 29/12/2017 18:11, Chris Angelico wrote:
>>
>> On Sat, Dec 30, 2017 at 4:13 AM, bartc  wrote:
>>>
>>> If you want to translate code from one language to another, and the
>>> source
>>> language uses gotos, or uses control structures not available in the
>>> target
>>> language, then gotos would be very useful in the latter.
>>>
>>
>> As has already been said in this thread, a competent FORTRAN
>> programmer can write FORTRAN code in any language. But if you want to
>> actually write Python code, instead of writing FORTRAN code that gets
>> run through a Python interpreter, you have to grok the Python way of
>> doing things.
>
>
> That's not true. People should be able to write code as they like using the
> nearest available language and using the style they are most adept in and
> that they find comfortable. /Especially/ if they are coding for themselves
> rather as part of some organisation or within a team.
>
> The choice of language may enforce some changes, but that should be the
> extent of it.
>
> A lot of the so-called 'Pythonic' style I frankly don't care for.
>
> I like to write code in a simple, clean, universal style that everyone can
> understand.
>
> That doesn't mean it has to look like Fortran.

Why are you using a Python interpreter then? Why are you here on
python-list, talking about Python? There must be SOME reason for using
this language rather than another.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Goto

[bartc]

On 29/12/2017 18:11, Chris Angelico wrote:

On Sat, Dec 30, 2017 at 4:13 AM, bartc  wrote:

If you want to translate code from one language to another, and the source
language uses gotos, or uses control structures not available in the target
language, then gotos would be very useful in the latter.



As has already been said in this thread, a competent FORTRAN
programmer can write FORTRAN code in any language. But if you want to
actually write Python code, instead of writing FORTRAN code that gets
run through a Python interpreter, you have to grok the Python way of
doing things.


That's not true. People should be able to write code as they like using 
the nearest available language and using the style they are most adept 
in and that they find comfortable. /Especially/ if they are coding for 
themselves rather as part of some organisation or within a team.


The choice of language may enforce some changes, but that should be the 
extent of it.


A lot of the so-called 'Pythonic' style I frankly don't care for.

I like to write code in a simple, clean, universal style that everyone 
can understand.


That doesn't mean it has to look like Fortran.


You can't do that by mechanically transforming source
code into the syntax of a different language.


(Actually that's exactly what a project of mine from a few years ago was 
trying to do.


Example of 'binary trees' benchmark:

source syntax:https://pastebin.com/raw/bgfKw2pq

generated Python: https://pastebin.com/raw/XJWjWzpw)

Here, you normally had to be aware when writing in the source language, 
of what target language you were using. Although sometimes exactly the 
same source translated to several targets including Python and Lisp. 
Anyway, this was unsatisfactory as a universal syntax that could be 
translated to any language.)



People who try to tell you that all programming languages are
identical, just with different syntax, are doing you a disservice.
Lisp is not Python is not REXX is not C is not DeScribe Macro
Language. (Especially the latter. Do NOT try to write C code in DML.
It'll look ugly. Trust me.


My experiment showed that such people have a point.

--
bartc
--
https://mail.python.org/mailman/listinfo/python-list

Re: Goto (Posting On Python-List Prohibited)

[Chris Angelico]

On Tue, Jan 2, 2018 at 9:11 AM,   wrote:
> On Monday, January 1, 2018 at 9:35:06 PM UTC, Chris Angelico wrote:
>> On Tue, Jan 2, 2018 at 7:16 AM, Chris Green wrote:
>> > Dennis Lee Bieber wrote:
>> >>
>> >> Well... "break" does bypass the rest of the block, but it still 
>> >> exits
>> >> via the end of the block. I have a tendency to try for one "return" per
>> >> procedure (so I'm more likely to have an "if ...: break" then "if ...:
>> >> return").
>> >
>> > I have always tried to enforce 'only one return per function'.  If
>> > there are multiple returns it makes maintenance very difficult as
>> > 'clear up' code can get bypassed.
>> >
>>
>> Isn't that why try/finally exists? No matter how many 'return'
>> statements you have, there's always exceptions to bypass any naive
>> cleanup code; and no matter how many returns you have, 'finally'
>> blocks still execute before return.
>>
>> ChrisA
>
> What happened to context managers?
>

They're a way of wrapping up repeatedly-used try/finally blocks. The
try/finally construct is the underlying functionality. In any case,
the same behaviour can be used by either, so yes, if you have cleanup
code and you're using 'with x:' rather than try/finally, it still fits
into the same concept that I'm describing, and still guarantees that
the cleanup code is executed before return.

(Yes, I know it's possible to bypass finally blocks. But the methods
for doing so (eg hard-aborting) also bypass the actual return, so the
"before return" part is still valid. If you're doing things that
depend on cleanup outside the process, like deleting temporary files,
you'll need something more than try/finally. But in that case, there's
no other code layout that would help you anyway.)

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Goto (Posting On Python-List Prohibited)

[breamoreboy]

On Monday, January 1, 2018 at 9:35:06 PM UTC, Chris Angelico wrote:
> On Tue, Jan 2, 2018 at 7:16 AM, Chris Green wrote:
> > Dennis Lee Bieber wrote:
> >>
> >> Well... "break" does bypass the rest of the block, but it still 
> >> exits
> >> via the end of the block. I have a tendency to try for one "return" per
> >> procedure (so I'm more likely to have an "if ...: break" then "if ...:
> >> return").
> >
> > I have always tried to enforce 'only one return per function'.  If
> > there are multiple returns it makes maintenance very difficult as
> > 'clear up' code can get bypassed.
> >
> 
> Isn't that why try/finally exists? No matter how many 'return'
> statements you have, there's always exceptions to bypass any naive
> cleanup code; and no matter how many returns you have, 'finally'
> blocks still execute before return.
> 
> ChrisA

What happened to context managers?

--
Kindest regards.

Mark Lawrence.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Goto (Posting On Python-List Prohibited)

[Chris Angelico]

On Tue, Jan 2, 2018 at 7:16 AM, Chris Green  wrote:
> Dennis Lee Bieber  wrote:
>>
>> Well... "break" does bypass the rest of the block, but it still exits
>> via the end of the block. I have a tendency to try for one "return" per
>> procedure (so I'm more likely to have an "if ...: break" then "if ...:
>> return").
>
> I have always tried to enforce 'only one return per function'.  If
> there are multiple returns it makes maintenance very difficult as
> 'clear up' code can get bypassed.
>

Isn't that why try/finally exists? No matter how many 'return'
statements you have, there's always exceptions to bypass any naive
cleanup code; and no matter how many returns you have, 'finally'
blocks still execute before return.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Goto (Posting On Python-List Prohibited)

[Chris Green]

Dennis Lee Bieber  wrote:
> 
> Well... "break" does bypass the rest of the block, but it still exits
> via the end of the block. I have a tendency to try for one "return" per
> procedure (so I'm more likely to have an "if ...: break" then "if ...:
> return"). 

I have always tried to enforce 'only one return per function'.  If
there are multiple returns it makes maintenance very difficult as
'clear up' code can get bypassed.

-- 
Chris Green
·
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Goto (Posting On Python-List Prohibited)

[John Q Hacker]

Sorry, delete string "n't".  I mean that you would strcuture your code
with that architecture.

Hate that.

marxos

On 1/1/18, John Q Hacker  wrote:
>>> I don’t use gotos in C code. Why should it be “harder” in a higher-level
>>> language?
>>
>> Good for you.
>>
>> Looking at 14 million lines of Linux kernel sources, which are in C,
>> over 100,000 of them use 'goto'. About one every 120 lines.
>
> Most use of goto's implies a lack of understanding of the unseen
> architecture of the problem domain itself (otherwise, you wouldn't
> have structured your program with that architecture).  The only
> remaining use is optimization, and most of that is probably premature,
> as use of gotos *can* make things hard to understand, but using labels
> is a pretty happy medium.
>
> Marxos
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Goto (Posting On Python-List Prohibited)

[John Q Hacker]

>> I don’t use gotos in C code. Why should it be “harder” in a higher-level
>> language?
>
> Good for you.
>
> Looking at 14 million lines of Linux kernel sources, which are in C,
> over 100,000 of them use 'goto'. About one every 120 lines.

Most use of goto's implies a lack of understanding of the unseen
architecture of the problem domain itself (otherwise, you wouldn't
have structured your program with that architecture).  The only
remaining use is optimization, and most of that is probably premature,
as use of gotos *can* make things hard to understand, but using labels
is a pretty happy medium.

Marxos
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Goto (Posting On Python-List Prohibited)

[From]

  




   (Posting On Python-List Prohibited)



why ?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Goto (Posting On Python-List Prohibited)

[bartc]

On 01/01/2018 15:06, From wrote:
   



 


(Posting On Python-List Prohibited)



 why ?



Huh?

I'm posting to the usenet group comp.lang.python (an off-topic reply to 
an off-topic remark, but it happens).


I've no idea what the prohibited part is about, if that's what you're 
posting about. But there have been dozens of other messages with the 
same subject.

--
https://mail.python.org/mailman/listinfo/python-list

Re: Goto (Posting On Python-List Prohibited)

[bartc]

On 01/01/2018 14:54, Peter J. Holzer wrote:

On 2017-12-30 11:07:56 -0500, Dennis Lee Bieber wrote:



Yes. I don't know any language which enforces "pure" structured
programming. They all have some constructs (goto, break, return,
exceptions, ...) to leave a block early. I don't think that invalidates
my point that the concept of structured programming predates Pascal.


Functional languages?

Some banish not only goto, but the concepts of assignments, and variables.

And even functions have to be pure with no side-effects, which makes I/O 
a problem.


They are really intent on making life difficult.

--
bartc

--
https://mail.python.org/mailman/listinfo/python-list

Re: Goto (Posting On Python-List Prohibited)

[Peter J. Holzer]

On 2017-12-30 11:07:56 -0500, Dennis Lee Bieber wrote:
> On Sat, 30 Dec 2017 13:46:14 +0100, "Peter J. Holzer" 
> declaimed the following:
> 
> >I don't think this is correct. Structured programming is much older:
> >ALGOL 60 was already a block structured language and Dijkstra wrote
> >"goto considered harmful" in the late 1960s. Pascal appeared in 1970, C
> >in 1974. To me (who learned to program in BASIC on a CP/M machine), C
> >is very much a structured programming language. If structured
> >programming gained traction around 1980, it might even have been because
> >structured languages like C with good performance became widely
> >available.
> >
>   There is a slight difference between just being block structured and
> full structured programming (at the time "one-entry/one-exit per
> construct".

I'd say there is a rather big difference: One is a programming paradigm,
the other a syntactic aid for the former. You can do structured
programming in assembler (I did in BASIC), but it is a lot easier and
natural in a block-structured language. I wasn't present when ALGOL was
invented (I wasn't even born then), but I am sure that the inventors
shared much of the mindset of "structured programming" (although the
name may not yet have been invented).

> Even Pascal still had a GOTO statement,

Yes. I don't know any language which enforces "pure" structured
programming. They all have some constructs (goto, break, return,
exceptions, ...) to leave a block early. I don't think that invalidates
my point that the concept of structured programming predates Pascal.

> and flow-charts were still part of documentation at school.

We learned about them in the 80's, too (along with Nassi-Shneiderman
diagrams). And in fact I still use them sometimes (although more
frequently to document processes for humans than for computers).
(I don't use NS diagrams at all anymore: They have no advantages over
pseudo code for me.)

>   The /teaching/ of structured programming as a discipline didn't really
> show up until my final year in college (79-80) and the first few years at
> Lockheed

I can't comment on how wide-spread teaching of structured programming
was, since I am too young. But since Pascal was explicitely intended as
a teaching language for structured programming, there must have been at
least a few professors to teach it in the late 1960's.

> -- which was also a time period when such abominations as TEXTFOR,
> MORTRAN, and RATFOR were created to allow for doing structured programming
> in FORTRAN-IV

And regardless of the quality (or lack thereof) of these preprocessors
I'd argue that they were created (and used) because at the time many
programmers thought that structured programming was a good idea. 

Is there any mainstream (procedural) computer language invented after
1970 which doesn't try to encourage structured programming?

hp

-- 
   _  | Peter J. Holzer| we build much bigger, better disasters now
|_|_) || because we have much more sophisticated
| |   | h...@hjp.at | management tools.
__/   | http://www.hjp.at/ | -- Ross Anderson 


signature.asc
Description: PGP signature
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Goto (Posting On Python-List Prohibited)

[breamoreboy]

On Sunday, December 31, 2017 at 6:56:16 PM UTC, bartc wrote:
> On 31/12/2017 17:01, breamoreboy wrote:
> 
> >Further I've never once in 17 years of using Python been tearing my hair out 
> >over the lack of goto
> 
> Neither have I over all the advanced features of Python I never use, and 
> for double that number of years.

I suggest that you steer well clear of all of Python's advanced features until 
you understand the Python philosophy as laid down in the Zen of Python.  
However I cannot see that happening as you seem to dispute everything about 
Python, flying in the face of any advice that you get from all the very 
experienced Pythonistas who frequent this place.  You must have access to the 
PSU's time machine if you've 34 years experience of Python as it hasn't been 
out that long.

> 
> Yet for some they will be as indispensable as they are incomprehensible 
> to others.

Let's all go back to machine code.

--
Kindest regards.

Mark Lawrence.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Goto (Posting On Python-List Prohibited)

[bartc]

On 01/01/2018 00:40, MRAB wrote:

On 2017-12-31 23:21, bartc wrote:


[Block delimiting]


proc fn2(int a)=

...

end

(or possibly "inline f123=").

[snip]

OT: if "case ... esac" and "if ... fi", why not "proc ... corp"? :-)


(I don't think Algol-68 used corp otherwise it might have been copied 
too. But I also have 'function', and 'noitcnuf' would be a bit much.


Anyway in this variation of the syntax, there is a choice of block endings.

So 'case' can be closed with 'end', 'endcase', 'end case' or 'esac'.

With loops like while-do, either 'while' or 'do' can be the keyword.

For some kinds of blocks, (...) can be used.

But there can't be no block ending as in Python; there has to be 
something. Indentation here is not significant.)


--
bartc
--
https://mail.python.org/mailman/listinfo/python-list

Re: Goto (Posting On Python-List Prohibited)

[bartc]

On 31/12/2017 17:01, breamore...@gmail.com wrote:


Further I've never once in 17 years of using Python been tearing my hair out 
over the lack of goto


Neither have I over all the advanced features of Python I never use, and 
for double that number of years.


Yet for some they will be as indispensable as they are incomprehensible 
to others.


--
https://mail.python.org/mailman/listinfo/python-list

Re: Goto (Posting On Python-List Prohibited)

[mm0fmf]

On 31/12/2017 17:01, breamore...@gmail.com wrote:

I would use functions every time as a modern compiler can inline them


This


Further I've never once in 17 years of using Python been tearing my hair out 
over the lack of goto


And this. (In my case only 6 years.)


--
https://mail.python.org/mailman/listinfo/python-list

Re: Goto (Posting On Python-List Prohibited)

[Ben Bacarisse]

bartc  writes:

> On 31/12/2017 22:09, Ben Bacarisse wrote:
>
>> No, you missed the point and did not address the question.  You said (now
>> cut)
>>
>> | If I thought introducing functions, whether local or not, as a way of
>> | avoiding goto was worth doing, I would do so.
>>
>> but I'm not sure you know if it's worth it or not.  So here's my
>> question again: what language (or languages) were you using when you
>> concluded that it was not worth using local functions to avoid gotos?
>> Maybe you had a bad experience from some language that did it badly.
>
> What makes you think I had a bad experience?

Nothing.  I was asking what experience you had that led to your
conclusion.  Knowing the language might explain the conclusion you came
to.

-- 
Ben.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Goto (Posting On Python-List Prohibited)

[MRAB]

On 2017-12-31 23:21, bartc wrote:

On 31/12/2017 22:09, Ben Bacarisse wrote:


No, you missed the point and did not address the question.  You said (now
cut)

| If I thought introducing functions, whether local or not, as a way of
| avoiding goto was worth doing, I would do so.

but I'm not sure you know if it's worth it or not.  So here's my
question again: what language (or languages) were you using when you
concluded that it was not worth using local functions to avoid gotos?
Maybe you had a bad experience from some language that did it badly.


What makes you think I had a bad experience? I posted a version using
Python a few hours ago (which needs the local function to be moved to
work properly).

The same example works in my language (one of them anyway), but I still
find a quick goto the simplest thing to do especially when the code is
not complete so I don't know what will be added or changed or moved,
which will be harder as soon a specific sequence is extracted into a
function.

Also, what would be the duplicated code is seen to 'belong' to one of
the options, rather than be anonymous.

(Here is the same example in my static language:
https://pastebin.com/raw/dX2FNK7a

fn1 uses goto. fn2 uses a local function (not very demanding here so it
works). fn3 uses the special 'block-call' feature which I no longer use
(but I haven't yet got rid of it).

I prefer fn1 and fn3 because the code stays inline. If I had some
inspiration for a better feature then I'd have fn4 and maybe fn5 too.)


The compiler could inline automatically, or you could be explicit:

proc fn2(int a)=
inline proc f123=
println "One"
println "Two"
println "Three"
end

case a
when 1 then
f123()

when 2 then
println "Four"

else
println "Other"
f123()
esac
end

(or possibly "inline f123=").

[snip]

OT: if "case ... esac" and "if ... fi", why not "proc ... corp"? :-)
--
https://mail.python.org/mailman/listinfo/python-list

Re: Goto (Posting On Python-List Prohibited)

[bartc]

On 31/12/2017 22:09, Ben Bacarisse wrote:


No, you missed the point and did not address the question.  You said (now
cut)

| If I thought introducing functions, whether local or not, as a way of
| avoiding goto was worth doing, I would do so.

but I'm not sure you know if it's worth it or not.  So here's my
question again: what language (or languages) were you using when you
concluded that it was not worth using local functions to avoid gotos?
Maybe you had a bad experience from some language that did it badly.


What makes you think I had a bad experience? I posted a version using 
Python a few hours ago (which needs the local function to be moved to 
work properly).


The same example works in my language (one of them anyway), but I still 
find a quick goto the simplest thing to do especially when the code is 
not complete so I don't know what will be added or changed or moved, 
which will be harder as soon a specific sequence is extracted into a 
function.


Also, what would be the duplicated code is seen to 'belong' to one of 
the options, rather than be anonymous.


(Here is the same example in my static language: 
https://pastebin.com/raw/dX2FNK7a


fn1 uses goto. fn2 uses a local function (not very demanding here so it 
works). fn3 uses the special 'block-call' feature which I no longer use 
(but I haven't yet got rid of it).


I prefer fn1 and fn3 because the code stays inline. If I had some 
inspiration for a better feature then I'd have fn4 and maybe fn5 too.)


Within Python, I touched on performance issues in my earlier post. (A 
local function apparently involves an extra assignment - per function - 
each time the containing function is called.)



(Which is likely to cause problems if the code includes breaks, or
gotos if the language has them.)


Good grief!  That is exactly the sort of code you should not re-use by
jumping to it.  There are myriad potential problems and putting the code
into a function will allow the compiler to diagnose lots of them.


OK, forget the gotos then. But a block can still contain break or return 
(and in my syntax, several other loop controls). It loses context as 
soon as it's hoisted into a function.


--
bartc
--
https://mail.python.org/mailman/listinfo/python-list

Re: Goto (Posting On Python-List Prohibited)

[Ben Bacarisse]

bartc  writes:

> On 31/12/2017 15:02, Ben Bacarisse wrote:
>> bartc  writes:
>
>> I think there's a problem with that.  Standard C does not have them, you
>> said your language does not implement them properly
>
> (The real problem is I don't remember local functions being used
> anywhere else. It's an idiom I'm not used to and that apparently few
> other people use. Except perhaps in Python where they do to use
> advanced features over simpler ones.)
>
>  and I think you are
>> new(ish) to Python.  What language did you try them in?  It may be that
>> it was overly complex in that language.  The idea is clean and simple.
>
> It's not simple to implement. Not if you want full access to the
> non-static variables of the containing function(s). It doesn't sound
> that efficient either.

No, you missed the point and did not address the question.  You said (now
cut)

| If I thought introducing functions, whether local or not, as a way of
| avoiding goto was worth doing, I would do so.

but I'm not sure you know if it's worth it or not.  So here's my
question again: what language (or languages) were you using when you
concluded that it was not worth using local functions to avoid gotos?
Maybe you had a bad experience from some language that did it badly.

>>> So in this case I disagree with dragging in named functions and
>>> introducing an extra level of control flow just to avoid duplicating
>>> half a dozen lines of code. I would just duplicate those lines (with a
>>> comment that they have to match the other set so that they are
>>> maintained in sync).
>>
>> The suggestion was to use them to avoid gotos.  If duplicating is a good
>> idea (and it's a hard line to draw) then we are not talking about the
>> same cases.  Given the choice of "dragging in named functions" and
>> dragging in named blocks and gotos, I would choose the functions every
>> time.
>
> The blocks don't need to be dragged; they are already in place!
>
> It's funny because in c.l.c you're always advocating keep declarations
> as close to the point of use as possible. Here you appear to be saying
> the opposite: taking code away from the primary point of use.

If a language allowed me to declare a local function at the point of
first use, I'd do that, but there are special reasons why that is not a
reasonable thing to do in most cases.  None the less, it's not
inconsistent to prefer one less than perfect option to another much less
than perfect option.

However, we're debating an entirely abstract notion.  What is a typical
use for this "re-use" goto idiom?  Maybe I'll prefer the goto version
over any of the alternatives when I see an actual use.

> (Which is likely to cause problems if the code includes breaks, or
> gotos if the language has them.)

Good grief!  That is exactly the sort of code you should not re-use by
jumping to it.  There are myriad potential problems and putting the code
into a function will allow the compiler to diagnose lots of them.

If you really are jumping to re-use code that includes gotos I suggest
the whole thing needs re-design.

-- 
Ben.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Goto (Posting On Python-List Prohibited)

[Chris Angelico]

On Mon, Jan 1, 2018 at 6:29 AM, bartc  wrote:
> You'll need to give an example I think. Suppose I start with this:
>
> def fn(a):
> if a==1:
> print ("One")
> print ("Two")
> print ("Three")
> elif a==2:
> print ("Four")
> else:
> print ("Other")
> print ("One")
> print ("Two")
> print ("Three")
>
> I want to share the lines that print One Two Three, so I create an inline
> function, defined as close as possible to the original code:
>
> def fn2(a):
> if a==1:
> def F123():
> print ("One")
> print ("Two")
> print ("Three")
> F123()
> elif a==2:
> print ("Four")
> else:
> print ("Other")
> F123()
>
> However, if I call this with fn2(3), it says that variable F123 has not been
> assigned.

Right, so you'd move it one line up (or move the 'if' down to below
the function definition), thus the larger block of code stays where it
is.

> Note also that a goto, and a function call, don't do the same thing. The
> function will return, the goto won't.

Not sure what you mean by "return", because what you effectively do is
create a name for a block of code, and then use (call) that block of
code more than once. That makes it easy to comprehend. With the goto,
you have to go look at the body below to figure out what happens.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Goto (Posting On Python-List Prohibited)

[bartc]

On 31/12/2017 19:29, bartc wrote:

[Ignore the original, incomplete version of my post, which appears after 
the sig.


I decided to actually try it out for real instead of just guessing!

Good thing too.]
--
https://mail.python.org/mailman/listinfo/python-list

Re: Goto (Posting On Python-List Prohibited)

[bartc]

On 31/12/2017 17:06, Chris Angelico wrote:

On Mon, Jan 1, 2018 at 3:55 AM, bartc  wrote:

The suggestion was to use them to avoid gotos.  If duplicating is a good
idea (and it's a hard line to draw) then we are not talking about the
same cases.  Given the choice of "dragging in named functions" and
dragging in named blocks and gotos, I would choose the functions every
time.



The blocks don't need to be dragged; they are already in place!

It's funny because in c.l.c you're always advocating keep declarations as
close to the point of use as possible. Here you appear to be saying the
opposite: taking code away from the primary point of use.


I don't understand the issue here. All you need to do is add a "def"
statement header in front of the block of code. And maybe indent it
further, although if you're unifying "if/elif" subtrees, that'll
cancel out the indentation level change. The block of code stays at or
near its first use.


You'll need to give an example I think. Suppose I start with this:

def fn(a):
if a==1:
print ("One")
print ("Two")
print ("Three")
elif a==2:
print ("Four")
else:
print ("Other")
print ("One")
print ("Two")
print ("Three")

I want to share the lines that print One Two Three, so I create an 
inline function, defined as close as possible to the original code:


def fn2(a):
if a==1:
def F123():
print ("One")
print ("Two")
print ("Three")
F123()
elif a==2:
print ("Four")
else:
print ("Other")
F123()

However, if I call this with fn2(3), it says that variable F123 has not 
been assigned.


(I'm not sure what overheads are associated with nested functions. 
Presumably its byte-code is done once, but is there any other setup of 
F123 associated with each call of fn2()? Even when a==2 so that F123() 
is not called?


A brief test [not using print()] showed it was a little slower having 
F123 inside fn2() - and outside the if-statement to make it work - than 
having F123 outside. And having to call F123() anyway instead of just 
having the inline code makes it a little slower too.


Although this would need to be balanced by the cost of the alternative, 
whether a goto or whatever.)


Note also that a goto, and a function call, don't do the same thing. The 
function will return, the goto won't. In my example all paths will 
return, in others this will have to be taken care of.


--
bartc












 Don't forget that after turning a block into a def-function in-place, 
it will need to be followed by a call to it:


  if X:
 A
 B
 C
  elif ...
  else:
 A
 B
 C

This becomes:

   if X:
  def F():
 A
 B
 C
  F()
   elif...
   else
  F()

(Is the def statement executed once during byte-code compilation? Or can 
it give different result each time depending on what globals are visible 
within F? Will there at least be a set-up overhead for F each time



Note that calling a local function is not quite a drop-in replacement for



Once again, Bart, you're scorning something that you don't have much
(any?) experience with. Look at how the feature is used before you
hate on it.

ChrisA



--
https://mail.python.org/mailman/listinfo/python-list

Re: Goto (Posting On Python-List Prohibited)

[breamoreboy]

On Sunday, December 31, 2017 at 3:02:41 PM UTC, Ben Bacarisse wrote:
> bartc  writes:
> 
> > On 31/12/2017 12:41, Chris Angelico wrote:
> >> On Sun, Dec 31, 2017 at 11:33 PM, bartc  wrote:
> >>> On 30/12/2017 23:54, Chris Angelico wrote:
> >
>  I've written code that uses dirty tricks like that to avoid
>  duplication. It's at least as much of a problem as actual duplication
>  is. Generally, the 'goto' solution results in subsequent programmers
>  (such as my future selves) staring at the code for 30-60 seconds to
>  figure out what it's doing. I don't like to do that to myself, much
>  less to people I actually admire and respect.
> >>>
> >>> The problem is having to stare at the code for even longer to figure out 
> >>> the
> >>> even dirtier tricks you had to use to avoid gotos.
> >>
> >> Dirtier tricks like... named functions?
> >
> > I like to write clean and readable code. If I thought introducing
> > functions, whether local or not, as a way of avoiding goto was worth
> > doing, I would do so.
> 
> I think there's a problem with that.  Standard C does not have them, you
> said your language does not implement them properly and I think you are
> new(ish) to Python.  What language did you try them in?  It may be that
> it was overly complex in that language.  The idea is clean and simple.
> 
> > So in this case I disagree with dragging in named functions and
> > introducing an extra level of control flow just to avoid duplicating
> > half a dozen lines of code. I would just duplicate those lines (with a
> > comment that they have to match the other set so that they are
> > maintained in sync).
> 
> The suggestion was to use them to avoid gotos.  If duplicating is a good
> idea (and it's a hard line to draw) then we are not talking about the
> same cases.  Given the choice of "dragging in named functions" and
> dragging in named blocks and gotos, I would choose the functions every
> time.
> 
> 
> -- 
> Ben.

I would use functions every time as a modern compiler can inline them, 
something described here https://en.wikipedia.org/wiki/Inline_expansion for the 
benefit of newbies.  Further I've never once in 17 years of using Python been 
tearing my hair out over the lack of goto as there are numerous examples of how 
to avoid them.  This thread is yet another storm in a thimble.

--
Kindest regards.

Mark Lawrence.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Goto (Posting On Python-List Prohibited)

[Chris Angelico]

On Mon, Jan 1, 2018 at 3:55 AM, bartc  wrote:
>> The suggestion was to use them to avoid gotos.  If duplicating is a good
>> idea (and it's a hard line to draw) then we are not talking about the
>> same cases.  Given the choice of "dragging in named functions" and
>> dragging in named blocks and gotos, I would choose the functions every
>> time.
>
>
> The blocks don't need to be dragged; they are already in place!
>
> It's funny because in c.l.c you're always advocating keep declarations as
> close to the point of use as possible. Here you appear to be saying the
> opposite: taking code away from the primary point of use.

I don't understand the issue here. All you need to do is add a "def"
statement header in front of the block of code. And maybe indent it
further, although if you're unifying "if/elif" subtrees, that'll
cancel out the indentation level change. The block of code stays at or
near its first use.

Once again, Bart, you're scorning something that you don't have much
(any?) experience with. Look at how the feature is used before you
hate on it.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Goto (Posting On Python-List Prohibited)

[bartc]

On 31/12/2017 15:02, Ben Bacarisse wrote:

bartc  writes:



I think there's a problem with that.  Standard C does not have them, you
said your language does not implement them properly


(The real problem is I don't remember local functions being used 
anywhere else. It's an idiom I'm not used to and that apparently few 
other people use. Except perhaps in Python where they do to use advanced 
features over simpler ones.)


 and I think you are

new(ish) to Python.  What language did you try them in?  It may be that
it was overly complex in that language.  The idea is clean and simple.


It's not simple to implement. Not if you want full access to the 
non-static variables of the containing function(s). It doesn't sound 
that efficient either.



So in this case I disagree with dragging in named functions and
introducing an extra level of control flow just to avoid duplicating
half a dozen lines of code. I would just duplicate those lines (with a
comment that they have to match the other set so that they are
maintained in sync).


The suggestion was to use them to avoid gotos.  If duplicating is a good
idea (and it's a hard line to draw) then we are not talking about the
same cases.  Given the choice of "dragging in named functions" and
dragging in named blocks and gotos, I would choose the functions every
time.


The blocks don't need to be dragged; they are already in place!

It's funny because in c.l.c you're always advocating keep declarations 
as close to the point of use as possible. Here you appear to be saying 
the opposite: taking code away from the primary point of use.


(Which is likely to cause problems if the code includes breaks, or gotos 
if the language has them.)


I think there is a way to solve this pattern via special language 
features, while writing the main code primarily inline and in a natural 
structure, but I haven't found a satisfactory method yet. I don't think 
local functions is it.


(And perhaps a solution lies outside the language such as within an 
editor, to allow sharing of the same block of code in multiple locations.)


--
bartc
--
https://mail.python.org/mailman/listinfo/python-list

Re: Goto (Posting On Python-List Prohibited)

[Ben Bacarisse]

bartc  writes:

> On 31/12/2017 12:41, Chris Angelico wrote:
>> On Sun, Dec 31, 2017 at 11:33 PM, bartc  wrote:
>>> On 30/12/2017 23:54, Chris Angelico wrote:
>
 I've written code that uses dirty tricks like that to avoid
 duplication. It's at least as much of a problem as actual duplication
 is. Generally, the 'goto' solution results in subsequent programmers
 (such as my future selves) staring at the code for 30-60 seconds to
 figure out what it's doing. I don't like to do that to myself, much
 less to people I actually admire and respect.
>>>
>>> The problem is having to stare at the code for even longer to figure out the
>>> even dirtier tricks you had to use to avoid gotos.
>>
>> Dirtier tricks like... named functions?
>
> I like to write clean and readable code. If I thought introducing
> functions, whether local or not, as a way of avoiding goto was worth
> doing, I would do so.

I think there's a problem with that.  Standard C does not have them, you
said your language does not implement them properly and I think you are
new(ish) to Python.  What language did you try them in?  It may be that
it was overly complex in that language.  The idea is clean and simple.

> So in this case I disagree with dragging in named functions and
> introducing an extra level of control flow just to avoid duplicating
> half a dozen lines of code. I would just duplicate those lines (with a
> comment that they have to match the other set so that they are
> maintained in sync).

The suggestion was to use them to avoid gotos.  If duplicating is a good
idea (and it's a hard line to draw) then we are not talking about the
same cases.  Given the choice of "dragging in named functions" and
dragging in named blocks and gotos, I would choose the functions every
time.


-- 
Ben.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Goto (Posting On Python-List Prohibited)

[bartc]

On 31/12/2017 12:41, Chris Angelico wrote:

On Sun, Dec 31, 2017 at 11:33 PM, bartc  wrote:

On 30/12/2017 23:54, Chris Angelico wrote:



I've written code that uses dirty tricks like that to avoid
duplication. It's at least as much of a problem as actual duplication
is. Generally, the 'goto' solution results in subsequent programmers
(such as my future selves) staring at the code for 30-60 seconds to
figure out what it's doing. I don't like to do that to myself, much
less to people I actually admire and respect.



The problem is having to stare at the code for even longer to figure out the
even dirtier tricks you had to use to avoid gotos.



Dirtier tricks like... named functions?


I like to write clean and readable code. If I thought introducing 
functions, whether local or not, as a way of avoiding goto was worth 
doing, I would do so.


So in this case I disagree with dragging in named functions and 
introducing an extra level of control flow just to avoid duplicating 
half a dozen lines of code. I would just duplicate those lines (with a 
comment that they have to match the other set so that they are 
maintained in sync).


For other uses of goto, I've introduced (not in Python or C but my own 
stuff) features to avoid the need some of those uses.


For example, extra loop controls, and loop controls that work with 
nested loops. I've also experimented with a feature intended purely to 
get to common clean-up code, but that had little advantage over using 
goto other than not writing 'goto', and thus avoiding some of the stigma 
(but you will also know it will do a one-off forward jump to a common 
point).


(Actually, none of my code ever needs to use 'goto' anyway, as I can 
also write it as 'go to'. That's effective if anyone does a 'grep' on my 
code looking for 'goto' instances...)


--
bartc
--
https://mail.python.org/mailman/listinfo/python-list

Re: Goto (Posting On Python-List Prohibited)

[Chris Angelico]

On Sun, Dec 31, 2017 at 11:33 PM, bartc  wrote:
> On 30/12/2017 23:54, Chris Angelico wrote:
>>
>> On Sun, Dec 31, 2017 at 10:45 AM, bartc  wrote:
>>>
>>> On 30/12/2017 23:26, Gregory Ewing wrote:


 bartc wrote:
>
>
> B and C occur twice, so a goto is a quick way to reuse B and C without
> needing to duplicate code,



 This only works if the repeated part happens to be at the
 tail of each case.
>>>
>>>
>>>
>>> IME that seems to be the most common situation.
>>>
>>
>> I've written code that uses dirty tricks like that to avoid
>> duplication. It's at least as much of a problem as actual duplication
>> is. Generally, the 'goto' solution results in subsequent programmers
>> (such as my future selves) staring at the code for 30-60 seconds to
>> figure out what it's doing. I don't like to do that to myself, much
>> less to people I actually admire and respect.
>
>
> The problem is having to stare at the code for even longer to figure out the
> even dirtier tricks you had to use to avoid gotos.
>

Dirtier tricks like... named functions?

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Goto (Posting On Python-List Prohibited)

[bartc]

On 30/12/2017 23:54, Chris Angelico wrote:

On Sun, Dec 31, 2017 at 10:45 AM, bartc  wrote:

On 30/12/2017 23:26, Gregory Ewing wrote:


bartc wrote:


B and C occur twice, so a goto is a quick way to reuse B and C without
needing to duplicate code,



This only works if the repeated part happens to be at the
tail of each case.



IME that seems to be the most common situation.



I've written code that uses dirty tricks like that to avoid
duplication. It's at least as much of a problem as actual duplication
is. Generally, the 'goto' solution results in subsequent programmers
(such as my future selves) staring at the code for 30-60 seconds to
figure out what it's doing. I don't like to do that to myself, much
less to people I actually admire and respect.


The problem is having to stare at the code for even longer to figure out 
the even dirtier tricks you had to use to avoid gotos.



--
https://mail.python.org/mailman/listinfo/python-list

Re: Goto (Posting On Python-List Prohibited)

[Ben Bacarisse]

bartc  writes:

> On 30/12/2017 20:36, Ben Bacarisse wrote:
>> bartc  writes:
>>
>>> On 30/12/2017 16:53, mm0fmf wrote:
 On 30/12/2017 14:41, bartc wrote:
> it looks a bit naff

 Understatement of 2017.
>>>
>>> I'm honest about my own ideas, but my remarks were about the use of
>>> special symbols such as "::" and "@".
>>>
>>> Before completely dismissing it however, you should look at how
>>> another language such as Python can achieve the same thing.
>>>
>>> Namely, take any block of code within a function, and allow it to be
>>> executed or shared from anywhere else in the function, with the
>>> minimum of disruption.
>>
>> That's what a local function does and it does it with the clean
>> semantics of a function call.
>>
>> When this idea came up in comp.lang.c you could not see the point, yet
>> you appear to have a use-case common enough that you have a solution
>> worked out using gotos.
>
> C doesn't in general have local functions. My own languages don't
> implement them properly. So I tend not to use them.

But now you have good reason to change that.  Properly implemented they
do exactly what you want very neatly.  You can stick with gotos, of
course, but at least I hope you won't pour scorn on the idea of local
function if it comes up again.

>>> If it looks better than what I'd come up with, then I'll use that instead.
>>
>> What looks better is always going to be an unreliable and subjective
>> measure, but calling a named function almost certainly scales better and
>> will allow for better structuring (such as when one block needs to use
>> another one).
>
> Using a local (or even non-local) function is what I'm trying to
> avoid, as I prefer to keep the code inline, and not disrupt it too
> much.

That's what used to be called hacking.  You write it one way and then
spot that that block over there can be used here, but you don't tidy up
the code, you just jump to it!  In general, it is exactly the sort of
goto use that gave gotos a bad name.  Anyway, by their very nature, the
blocks you are talking about should not be inline since they don't
belong to any one execution path.


(I hope you don't mind this annotation -- over at comp.lang.c I just
remove text from my replies to you as is your preference, but people
here will not have seen that exchange and I prefer to mark edits.)

-- 
Ben.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Goto (Posting On Python-List Prohibited)

[MRAB]

On 2017-12-30 23:22, Gregory Ewing wrote:

Stefan Ram wrote:

  BASIC has

DEF FN...

  which /can/ define actual subroutines, limited to expressions.

  Now, what does this limitation remind me of?


The equivalent limitation in Python is nowhere near as bad,
since if you outgrow what lambda can do you can always
use a def instead. BASIC didn't have that option (unless
you were using one of the more advanced dialects, such
as BBC BASIC, which had a PROC statement).

PROC wasn't really a statement, but a prefix for a procedure name. There 
was also another prefix, FN, for functions.


DEF PROChello
print "Hello world!"
ENDPROC

DEF FNsquare(x)
= x * x

They even had LOCAL variables and parameter lists. The Acorn Archimedes 
range had an improved version of BBC BASIC.

--
https://mail.python.org/mailman/listinfo/python-list

Re: Goto (Posting On Python-List Prohibited)

[Chris Angelico]

On Sun, Dec 31, 2017 at 10:45 AM, bartc  wrote:
> On 30/12/2017 23:26, Gregory Ewing wrote:
>>
>> bartc wrote:
>>>
>>> B and C occur twice, so a goto is a quick way to reuse B and C without
>>> needing to duplicate code,
>>
>>
>> This only works if the repeated part happens to be at the
>> tail of each case.
>
>
> IME that seems to be the most common situation.
>

I've written code that uses dirty tricks like that to avoid
duplication. It's at least as much of a problem as actual duplication
is. Generally, the 'goto' solution results in subsequent programmers
(such as my future selves) staring at the code for 30-60 seconds to
figure out what it's doing. I don't like to do that to myself, much
less to people I actually admire and respect.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Goto (Posting On Python-List Prohibited)

[bartc]

On 30/12/2017 23:26, Gregory Ewing wrote:

bartc wrote:
B and C occur twice, so a goto is a quick way to reuse B and C without 
needing to duplicate code,


This only works if the repeated part happens to be at the
tail of each case.


IME that seems to be the most common situation.

 Any other situation and you're back to

local functions.



--
Bartc

--
https://mail.python.org/mailman/listinfo/python-list

Re: Goto (Posting On Python-List Prohibited)

[Gregory Ewing]

bartc wrote:
B and C occur twice, so a goto is a quick way to reuse B and C without 
needing to duplicate code,


This only works if the repeated part happens to be at the
tail of each case. Any other situation and you're back to
local functions.

--
Greg
--
https://mail.python.org/mailman/listinfo/python-list

Re: Goto (Posting On Python-List Prohibited)

[Gregory Ewing]

bartc wrote:
C doesn't in general have local functions. My own languages don't 
implement them properly. So I tend not to use them.


Looks like there's something circular going on here. You don't
have much experience of using local functions, so you don't
see a lot of value in them, so you haven't made the effort to
implement them in your own languages, so you don't get much
experience in using them.

--
Greg
--
https://mail.python.org/mailman/listinfo/python-list

Re: Goto (Posting On Python-List Prohibited)

[Gregory Ewing]

Stefan Ram wrote:

  BASIC has

DEF FN...

  which /can/ define actual subroutines, limited to expressions.

  Now, what does this limitation remind me of?


The equivalent limitation in Python is nowhere near as bad,
since if you outgrow what lambda can do you can always
use a def instead. BASIC didn't have that option (unless
you were using one of the more advanced dialects, such
as BBC BASIC, which had a PROC statement).

--
Greg
--
https://mail.python.org/mailman/listinfo/python-list

Re: Goto (Posting On Python-List Prohibited)

[Chris Angelico]

On Sun, Dec 31, 2017 at 9:43 AM, bartc  wrote:
> On 30/12/2017 20:36, Ben Bacarisse wrote:
>>
>> bartc  writes:
>>
>>> On 30/12/2017 16:53, mm0fmf wrote:

 On 30/12/2017 14:41, bartc wrote:
>
> it looks a bit naff


 Understatement of 2017.
>>>
>>>
>>> I'm honest about my own ideas, but my remarks were about the use of
>>> special symbols such as "::" and "@".
>>>
>>> Before completely dismissing it however, you should look at how
>>> another language such as Python can achieve the same thing.
>>>
>>> Namely, take any block of code within a function, and allow it to be
>>> executed or shared from anywhere else in the function, with the
>>> minimum of disruption.
>>
>>
>> That's what a local function does and it does it with the clean
>> semantics of a function call.
>>
>> When this idea came up in comp.lang.c you could not see the point, yet
>> you appear to have a use-case common enough that you have a solution
>> worked out using gotos.
>
>
> C doesn't in general have local functions. My own languages don't implement
> them properly. So I tend not to use them.
>
>>> If it looks better than what I'd come up with, then I'll use that
>>> instead.
>>
>>
>> What looks better is always going to be an unreliable and subjective
>> measure, but calling a named function almost certainly scales better and
>> will allow for better structuring (such as when one block needs to use
>> another one).
>
>
> Using a local (or even non-local) function is what I'm trying to avoid, as I
> prefer to keep the code inline, and not disrupt it too much.
>
> You may also want to execute a block only temporarily, or as part of a short
> test. So you don't want to go to the trouble of hoisting a block of code
> into a local function.
>
> (And in C, which has local block scopes, there would be trouble with
> visibility of all the variables the block uses, unless the local function is
> untidily placed right where the original block was.)
>

Okay, so a low level language lacks certain facilities. Great. What
has this to do with Python and goto? You *can* use nested functions.
And they can do everything you need of these sub-blocks (albeit with
some overhead).

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Goto (Posting On Python-List Prohibited)

[bartc]

On 30/12/2017 20:36, Ben Bacarisse wrote:

bartc  writes:


On 30/12/2017 16:53, mm0fmf wrote:

On 30/12/2017 14:41, bartc wrote:

it looks a bit naff


Understatement of 2017.


I'm honest about my own ideas, but my remarks were about the use of
special symbols such as "::" and "@".

Before completely dismissing it however, you should look at how
another language such as Python can achieve the same thing.

Namely, take any block of code within a function, and allow it to be
executed or shared from anywhere else in the function, with the
minimum of disruption.


That's what a local function does and it does it with the clean
semantics of a function call.

When this idea came up in comp.lang.c you could not see the point, yet
you appear to have a use-case common enough that you have a solution
worked out using gotos.


C doesn't in general have local functions. My own languages don't 
implement them properly. So I tend not to use them.



If it looks better than what I'd come up with, then I'll use that instead.


What looks better is always going to be an unreliable and subjective
measure, but calling a named function almost certainly scales better and
will allow for better structuring (such as when one block needs to use
another one).


Using a local (or even non-local) function is what I'm trying to avoid, 
as I prefer to keep the code inline, and not disrupt it too much.


You may also want to execute a block only temporarily, or as part of a 
short test. So you don't want to go to the trouble of hoisting a block 
of code into a local function.


(And in C, which has local block scopes, there would be trouble with 
visibility of all the variables the block uses, unless the local 
function is untidily placed right where the original block was.)


--
bartc
--
https://mail.python.org/mailman/listinfo/python-list

Re: Goto (Posting On Python-List Prohibited)

[William Ray Wing]

> On Dec 30, 2017, at 7:46 AM, Peter J. Holzer  wrote:
> 
> On 2017-12-29 19:09:35 -0500, Dennis Lee Bieber wrote:
>> On Fri, 29 Dec 2017 23:12:22 +, bartc  declaimed the
>> following:
>>> Looking at 14 million lines of Linux kernel sources, which are in C, 
>>> over 100,000 of them use 'goto'. About one every 120 lines.
>>> 
>> 
>>  C is a language that predates the "structured programming" concepts of
>> the late 70/early 80.
> 
> I don't think this is correct. Structured programming is much older:
> ALGOL 60 was already a block structured language and Dijkstra wrote
> "goto considered harmful" in the late 1960s. Pascal appeared in 1970, C
> in 1974. To me (who learned to program in BASIC on a CP/M machine), C
> is very much a structured programming language. If structured
> programming gained traction around 1980, it might even have been because
> structured languages like C with good performance became widely
> available.
> 
> That said, C lacks exception handling (well, there is setjmp/longjmp,
> but ...) and multi-level break/continue, so goto is often the cleanest
> way to abort what you are doing and start to clean up. Python has
> exception handling, and that removes most of the cases where you would
> use goto in C (the rest is probably mostly in micro-optimizations: If
> you care about the run-time difference between a goto and a subroutine
> call, you probably shouldn't use Python in the first place).
> 
>hp
> 

I’ve been watching this discussion ebb and flow - and finally can’t resist 
pointing folks here at the famous essay: “Real Programmers Don’t Use Pascal”.  
It has its own Wikipedia article at this point:

 https://en.wikipedia.org/wiki/Real_Programmers_Don't_Use_Pascal

A copy of the original essay appears here: 
https://www.ee.ryerson.ca/~elf/hack/realmen.html

Hopefully fun reading over a beer.

Bill


-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Goto (Posting On Python-List Prohibited)

[Chris Angelico]

On Sun, Dec 31, 2017 at 7:36 AM, Ben Bacarisse  wrote:
> bartc  writes:
>
>> On 30/12/2017 16:53, mm0fmf wrote:
>>> On 30/12/2017 14:41, bartc wrote:
 it looks a bit naff
>>>
>>> Understatement of 2017.
>>
>> I'm honest about my own ideas, but my remarks were about the use of
>> special symbols such as "::" and "@".
>>
>> Before completely dismissing it however, you should look at how
>> another language such as Python can achieve the same thing.
>>
>> Namely, take any block of code within a function, and allow it to be
>> executed or shared from anywhere else in the function, with the
>> minimum of disruption.
>
> That's what a local function does and it does it with the clean
> semantics of a function call.
>

The only downside that I can think of is performance - function calls
can be a bit heavy-weight. I'd be curious to see what a "lightweight
local function" would look like - it could have restrictive semantics
like "can only be called from the function that constructed it" and
then could behave like Bart's proposed "block of code". But I suspect
it wouldn't have all that many uses, compared to a *real* closure,
which can be passed around as its own entity.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Goto (Posting On Python-List Prohibited)

[Ben Bacarisse]

bartc  writes:

> On 30/12/2017 16:53, mm0fmf wrote:
>> On 30/12/2017 14:41, bartc wrote:
>>> it looks a bit naff
>>
>> Understatement of 2017.
>
> I'm honest about my own ideas, but my remarks were about the use of
> special symbols such as "::" and "@".
>
> Before completely dismissing it however, you should look at how
> another language such as Python can achieve the same thing.
>
> Namely, take any block of code within a function, and allow it to be
> executed or shared from anywhere else in the function, with the
> minimum of disruption.

That's what a local function does and it does it with the clean
semantics of a function call.

When this idea came up in comp.lang.c you could not see the point, yet
you appear to have a use-case common enough that you have a solution
worked out using gotos.

> If it looks better than what I'd come up with, then I'll use that instead.

What looks better is always going to be an unreliable and subjective
measure, but calling a named function almost certainly scales better and
will allow for better structuring (such as when one block needs to use
another one).

-- 
Ben.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Goto (Posting On Python-List Prohibited)

[Ian Kelly]

On Sat, Dec 30, 2017 at 8:41 AM, bartc  wrote:
> (I had introduced a special language feature just for this kind of thing,
> but it was unsatisfactory. Goto was simpler and understood by everyone. And
> portable to any other language - that hasn't done away with goto. But it
> worked like this (not Python):
>
> a:=20
>
> case a
> when 10 then
> fred::
> println "one"
>
> when 20 then
> @fred
> println "two"
>
> end
>
> Output is "one" "two" when a is 20.
>
> fred:: names a block, and @fred 'calls' that block, without having to move
> it out of context. Actually this goes beyond what 'goto' can do, as it can
> also 'come back'. But as you can see, it looks a bit naff. A bit 1970s.)

BASIC had this feature in the form of the GOSUB statement. Although it
used an explicit rather than implicit RETURN.

BASIC was an awful language for developing programs of any size,
though. Without actual subroutines and with only one variable scope,
most people developed the practice of using GOSUB and designating
specific global variables as pseudo-arguments in order to have some
limited form of parameter passing. That was the kind of environment
where GOTO really, really sucks and produces the monstrous spaghetti
code that gives it its bad reputation. With the restrictions of
languages like C (i.e. only allowing GOTO within a function) and with
a reasonable level of restraint, I don't think that the use of GOTO is
really that big of a deal.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Goto (Posting On Python-List Prohibited)

[MRAB]

On 2017-12-30 18:21, bartc wrote:

On 30/12/2017 16:53, mm0fmf wrote:

On 30/12/2017 14:41, bartc wrote:

it looks a bit naff


Understatement of 2017.


I'm honest about my own ideas, but my remarks were about the use of
special symbols such as "::" and "@".

Before completely dismissing it however, you should look at how another
language such as Python can achieve the same thing.

Namely, take any block of code within a function, and allow it to be
executed or shared from anywhere else in the function, with the minimum
of disruption.

If it looks better than what I'd come up with, then I'll use that instead.

Perhaps what you want is something closer to a local named subroutine 
that can directly access the local variables.

--
https://mail.python.org/mailman/listinfo/python-list

Re: Goto (Posting On Python-List Prohibited)

[bartc]

On 30/12/2017 16:53, mm0fmf wrote:

On 30/12/2017 14:41, bartc wrote:

it looks a bit naff


Understatement of 2017.


I'm honest about my own ideas, but my remarks were about the use of 
special symbols such as "::" and "@".


Before completely dismissing it however, you should look at how another 
language such as Python can achieve the same thing.


Namely, take any block of code within a function, and allow it to be 
executed or shared from anywhere else in the function, with the minimum 
of disruption.


If it looks better than what I'd come up with, then I'll use that instead.


--
bartc
--
https://mail.python.org/mailman/listinfo/python-list

Re: Goto (Posting On Python-List Prohibited)

[mm0fmf]

On 30/12/2017 14:41, bartc wrote:

it looks a bit naff


Understatement of 2017.

--
https://mail.python.org/mailman/listinfo/python-list

Re: Goto (Posting On Python-List Prohibited)

[bartc]

On 30/12/2017 03:05, Lawrence D’Oliveiro wrote:

On Saturday, December 30, 2017 at 12:12:23 PM UTC+13, bartc wrote:

Looking at 14 million lines of Linux kernel sources, which are in C,
over 100,000 of them use 'goto'. About one every 120 lines.


That kind of thing leads to spaghetti code.

Here  is an example I like to bring 
up: writing a Python extension module in C. As you know, this requires a lot of 
careful memory management to cope with errors and avoid either memory leaks or 
double-frees. The coding convention I came up with looks like this:

 ... initialize pointers to allocated storage to NULL ...
 do /*once*/
   {
 ... processing ...
 allocate some storage;
 if (error)
 break;
 ... more processing ...
 allocate more storage;
 if (error)
 break;
 ... even more processing ...
   }
 while (false);
 ... free allocated storage ...

Basically, it becomes possible to satisfy yourself, by inspection, that every 
possible control path through the above code will pass once, and only once, 
through the storage deallocation.

Things get slightly more complicated where allocation has to happen in a loop. 
Actually, that’s where the interesting cases happen. My technique can be 
adapted to cope elegantly with this, too--see the code.



I tend to use goto to share small sequences of code:

   if cond1:
  A
  B
   elif cond2:
  C
   elif cond3:
  D
  B
   elif cond4:
  C
   ...

Here, A, B, C, D represent small blocks of code. The conditions have to 
be tested in this order.



B and C occur twice, so a goto is a quick way to reuse B and C without 
needing to duplicate code, or go through the upheaval of extracting them 
to functions. (And then the code develops so that the two Bs /are/ 
different, and then you have to get rid of the function. Or the second C 
was temporary anyway.)


Any other way of doing it will obfuscate the structure:

   if cond1:
  A
   elif cond2 or (not cond3 and cond4):
  C
   elif cond3:
  D

   if cond1 or (not cond2 and cond3):
  B

I can no longer be sure if this right. Plus executing A, C, D can change 
the conditions if they are tested again.


(I had introduced a special language feature just for this kind of 
thing, but it was unsatisfactory. Goto was simpler and understood by 
everyone. And portable to any other language - that hasn't done away 
with goto. But it worked like this (not Python):


a:=20

case a
when 10 then
fred::
println "one"

when 20 then
@fred
println "two"

end

Output is "one" "two" when a is 20.

fred:: names a block, and @fred 'calls' that block, without having to 
move it out of context. Actually this goes beyond what 'goto' can do, as 
it can also 'come back'. But as you can see, it looks a bit naff. A bit 
1970s.)


--
bartc
--
https://mail.python.org/mailman/listinfo/python-list

Re: Goto (Posting On Python-List Prohibited)

[Peter J. Holzer]

On 2017-12-29 19:09:35 -0500, Dennis Lee Bieber wrote:
> On Fri, 29 Dec 2017 23:12:22 +, bartc  declaimed the
> following:
> >Looking at 14 million lines of Linux kernel sources, which are in C, 
> >over 100,000 of them use 'goto'. About one every 120 lines.
> >
> 
>   C is a language that predates the "structured programming" concepts of
> the late 70/early 80.

I don't think this is correct. Structured programming is much older:
ALGOL 60 was already a block structured language and Dijkstra wrote
"goto considered harmful" in the late 1960s. Pascal appeared in 1970, C
in 1974. To me (who learned to program in BASIC on a CP/M machine), C
is very much a structured programming language. If structured
programming gained traction around 1980, it might even have been because
structured languages like C with good performance became widely
available.

That said, C lacks exception handling (well, there is setjmp/longjmp,
but ...) and multi-level break/continue, so goto is often the cleanest
way to abort what you are doing and start to clean up. Python has
exception handling, and that removes most of the cases where you would
use goto in C (the rest is probably mostly in micro-optimizations: If
you care about the run-time difference between a goto and a subroutine
call, you probably shouldn't use Python in the first place).

hp

-- 
   _  | Peter J. Holzer| we build much bigger, better disasters now
|_|_) || because we have much more sophisticated
| |   | h...@hjp.at | management tools.
__/   | http://www.hjp.at/ | -- Ross Anderson 


signature.asc
Description: PGP signature
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Goto (Posting On Python-List Prohibited)

[Rustom Mody]

On Saturday, December 30, 2017 at 8:35:27 AM UTC+5:30, Lawrence D’Oliveiro 
wrote:
> On Saturday, December 30, 2017 at 12:12:23 PM UTC+13, bartc wrote:
> > Looking at 14 million lines of Linux kernel sources, which are in C, 
> > over 100,000 of them use 'goto'. About one every 120 lines.
> 
> That kind of thing leads to spaghetti code.
> 
> Here  is an example I like to bring 
> up: writing a Python extension module in C. As you know, this requires a lot 
> of careful memory management to cope with errors and avoid either memory 
> leaks or double-frees. The coding convention I came up with looks like this:
> 
> ... initialize pointers to allocated storage to NULL ...
> do /*once*/
>   {
> ... processing ...
> allocate some storage;
> if (error)
> break;
> ... more processing ...
> allocate more storage;
> if (error)
> break;
> ... even more processing ...
>   }
> while (false);
> ... free allocated storage ...
> 
> Basically, it becomes possible to satisfy yourself, by inspection, that every 
> possible control path through the above code will pass once, and only once, 
> through the storage deallocation.
> 
> Things get slightly more complicated where allocation has to happen in a 
> loop. Actually, that’s where the interesting cases happen. My technique can 
> be adapted to cope elegantly with this, too--see the code.

Bizarre how religions proliferate…
I wonder how many people who quote Dijkstra have read "goto statement considered
harmful". 
And that short letter was negative, aka "Don’t use goto!”

The more positive answer to the question: “Ok so then how to program?”
was "Structured Programming"
I am ready to bet that an even tinier percentage has ever seen that tome

And if one really got the gist of structuredness:
mapping an automaton with
state = label
transition = goto
is really the most clean structured mapping

One can do almost as well with a switch and (case) labels

You can make a virtue of the fact that python has neither
I call it blind religious genuflecting

BTW there can be quite good reasons for not putting¹ goto into a language
especially interpreted ones is that gotos tend to make semantics non 
compositional:

ie Say S₁ S₂ are two statements in the source language composed together into
a larger source statement S₁ □ S₂ which translates into T₁ ▽ T₂
Egs of S₁ □ S₂ could be ifthenelse sequencing etc
T₁ ▽ T₂ could be assembly code for S₁ followed by code for S₂ (for a compiler)
Or action of S₁ followed by action of S₂ (for interpreter)

Now if S₁ , S₂ has gotos jumping into each other this 
"homomorphic tree transforming model" becomes messed up

However in the face of exceptions² that are quite close to gotos I dont
think this logic would apply

Finally I would like to quote my teacher of programming who made a statement
that altered my next 30 years of programming life:

“What the goto does to control structure, the assignment does to data structure”

¹ The most important decisions for a language designer are what to leave out —
Nicklaus Wirth

² The original objectives of the language (Ada) included reliability,
readability of programs, formality of language definition, and even
simplicity. Gradually these objectives have been sacrificed in favor
of power, supposedly achieved by a plethora of features and notational
conventions, many of them unnecessary and some of them, like exception
handling, even dangerous
C.A.R. Hoare Turing lecture: 
https://amturing.acm.org/award_winners/hoare_4622167.cfm
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Goto (Posting On Python-List Prohibited)

[MRAB]

On 2017-12-29 23:12, bartc wrote:

On 29/12/2017 21:55, Lawrence D’Oliveiro wrote:

On Saturday, December 30, 2017 at 9:03:50 AM UTC+13, bartc wrote:

Why most newer, higher level languages don't, I don't know. Perhaps
because the people who design them want to make programming harder?


I don’t use gotos in C code. Why should it be “harder” in a higher-level 
language?



Good for you.

Looking at 14 million lines of Linux kernel sources, which are in C,
over 100,000 of them use 'goto'. About one every 120 lines.

My own low level sources use about one goto every 400 lines. It's hardly
a lot. If one is used, it's because it was handy to use it, until such
time as it can be replaced with proper logic. But such logic will
usually be more convoluted.

BTW, looking at 220,000 lines of CPython sources, in C (an old
distribution I had to hand), there are 2600 gotos, about one every 85
lines. And those are the ones are directly visible as gotos, and not
hidden behind macros.

I understand that on Linux, the CPython dispatcher makes use of label
pointers, using 'goto *opcode_targets[*next_instr++]' to do a faster
byte-code dispatch than using switch.

You I guess would have written it without that, and we'd all have to
suffer 10% slower speed (or whatever) for your principles. That's
assuming you could have got rid of the other 2600 gotos as well.

I too use goto in C code, principally to go to clean-up code after 
checking the result of a call.


In Python, on the other hand, I have automatic garbage collection, 
exceptions, etc.


It's OK for code that's close to the metal, but in high-level code? No.

Python has managed for >25 years without it, and I've yet to see a 
convincing use-case.

--
https://mail.python.org/mailman/listinfo/python-list

Re: Goto (Posting On Python-List Prohibited)

[Skip Montanaro]

Looking at 14 million lines of Linux kernel sources, which are in C, over
100,000 of them use 'goto'. About one every 120 lines.


Isn't C's goto statement restricted to the current function? I imagine
setjmp and longjmp calls might be more insidious.

Skip
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Goto (Posting On Python-List Prohibited)

[bartc]

On 29/12/2017 21:55, Lawrence D’Oliveiro wrote:

On Saturday, December 30, 2017 at 9:03:50 AM UTC+13, bartc wrote:

Why most newer, higher level languages don't, I don't know. Perhaps
because the people who design them want to make programming harder?


I don’t use gotos in C code. Why should it be “harder” in a higher-level 
language?



Good for you.

Looking at 14 million lines of Linux kernel sources, which are in C, 
over 100,000 of them use 'goto'. About one every 120 lines.


My own low level sources use about one goto every 400 lines. It's hardly 
a lot. If one is used, it's because it was handy to use it, until such 
time as it can be replaced with proper logic. But such logic will 
usually be more convoluted.


BTW, looking at 220,000 lines of CPython sources, in C (an old 
distribution I had to hand), there are 2600 gotos, about one every 85 
lines. And those are the ones are directly visible as gotos, and not 
hidden behind macros.


I understand that on Linux, the CPython dispatcher makes use of label 
pointers, using 'goto *opcode_targets[*next_instr++]' to do a faster 
byte-code dispatch than using switch.


You I guess would have written it without that, and we'd all have to 
suffer 10% slower speed (or whatever) for your principles. That's 
assuming you could have got rid of the other 2600 gotos as well.


--
bartc

--
https://mail.python.org/mailman/listinfo/python-list

Re: Goto

[bartc]

On 29/12/2017 21:56, Stefan Ram wrote:

Chris Angelico  writes:

On Sat, Dec 30, 2017 at 8:03 AM, D'Arcy Cain  wrote:

On 12/29/2017 02:25 PM, Chris Angelico wrote:

PHP also added goto to a later version.

Ahh, great choice of example. "It's okay - PHP does it."

I thought that that was a reason to not do it.

Often, yeah. Hence my comment that "hey, PHP has goto" is an excellent
choice of example.


   I already wrote this before, recently, in some newsgroup (here?):

   Knuth's algorithm's often use "goto"'s. When translating them into
   another language, it is helpful to be able to translate them as
   direct as possible. Having to change the algorithm in one's head
   to avoid "goto" while converting it to Python seems to be a
   source of errors.

   When a language has a "goto", one can then translate Knuth's
   algorithms more literally. One then can add tests. And /then/
   one can refactor step-by-step to an algorithm without "goto".




That sort of argument will never wash here:

"/I/ can write code without ever using 'goto'. So nobody else should 
ever need to use it either".


Forget about automatic code translators, automatic parser generators, 
automatic state machine translators, plus a host of other uses which 
goto could simplify.


--
https://mail.python.org/mailman/listinfo/python-list

Re: Goto

[Chris Angelico]

On Sat, Dec 30, 2017 at 8:03 AM, D'Arcy Cain  wrote:
> On 12/29/2017 02:25 PM, Chris Angelico wrote:
>>> PHP also added goto to a later version.
>>
>> Ahh, great choice of example. "It's okay - PHP does it."
>
> I thought that that was a reason to not do it.

Often, yeah. Hence my comment that "hey, PHP has goto" is an excellent
choice of example.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Goto

[D'Arcy Cain]

On 12/29/2017 02:25 PM, Chris Angelico wrote:
>> PHP also added goto to a later version.
> 
> Ahh, great choice of example. "It's okay - PHP does it."

I thought that that was a reason to not do it.

-- 
D'Arcy J.M. Cain
Vybe Networks Inc.
http://www.VybeNetworks.com/
IM:da...@vex.net VoIP: sip:da...@vybenetworks.com
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Goto

[bartc]

On 29/12/2017 20:25, Chris Angelico wrote:

On Sat, Dec 30, 2017 at 7:03 AM, bartc  wrote:

On 29/12/2017 18:55, MarkA wrote:


On Thu, 28 Dec 2017 00:58:48 -0200, Duram wrote:


How to use goto in python?

---
This email has been checked for viruses by AVG.
http://www.avg.com



Rather than ask how to use an unavailable statement (GOTO), why not
investigate why no modern languages use it?



Golang uses goto.

Lua didn't have goto but then added it.

PHP also added goto to a later version.


Ahh, great choice of example. "It's okay - PHP does it."


I don't know PHP, but I guess it has all the usual features that people 
can use to eliminate goto (ie. the ability to add extra, more convoluted 
code).


So presumably adding it had a net benefit.

Notice I said Lua and Golang also have it.

Adding it to a language doesn't mean people are obliged to use it.

--
bartc
--
https://mail.python.org/mailman/listinfo/python-list

Re: Goto

[Chris Angelico]

On Sat, Dec 30, 2017 at 7:03 AM, bartc  wrote:
> On 29/12/2017 18:55, MarkA wrote:
>>
>> On Thu, 28 Dec 2017 00:58:48 -0200, Duram wrote:
>>
>>> How to use goto in python?
>>>
>>> ---
>>> This email has been checked for viruses by AVG.
>>> http://www.avg.com
>>
>>
>> Rather than ask how to use an unavailable statement (GOTO), why not
>> investigate why no modern languages use it?
>
>
> Golang uses goto.
>
> Lua didn't have goto but then added it.
>
> PHP also added goto to a later version.

Ahh, great choice of example. "It's okay - PHP does it."

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Goto

[bartc]

On 29/12/2017 18:55, MarkA wrote:

On Thu, 28 Dec 2017 00:58:48 -0200, Duram wrote:


How to use goto in python?

---
This email has been checked for viruses by AVG.
http://www.avg.com


Rather than ask how to use an unavailable statement (GOTO), why not
investigate why no modern languages use it?


Golang uses goto.

Lua didn't have goto but then added it.

PHP also added goto to a later version.

That's the extent of my one minutes' research; I guess a few other 
newish languages might use it (plus any I create myself, and pile of 
older languages).


Why most newer, higher level languages don't, I don't know. Perhaps 
because the people who design them want to make programming harder? Or 
they are adept at doing without it, and expect everyone else to be 
equally so?


Nothing wrong with goto when you have a throwaway program to finish and 
an approaching deadline.


Overuse of goto in real applications would be a problem, but that's the 
same with any feature. In Python, you can define F as function, but then 
reassign any other arbitrary value to F, at any point in a program, at 
any time, and as many times as you like. That makes goto seem almost 
benign! (Except that Python would probably let you assign to labels...)


--
bartc

--
https://mail.python.org/mailman/listinfo/python-list

Re: Goto

[MarkA]

On Thu, 28 Dec 2017 00:58:48 -0200, Duram wrote:

> How to use goto in python?
> 
> ---
> This email has been checked for viruses by AVG.
> http://www.avg.com

Rather than ask how to use an unavailable statement (GOTO), why not 
investigate why no modern languages use it?

-- 
MarkA

You can safely assume that you have created God in your own image when it 
turns out that God hates all the same people you do.  -- Anne Lamott
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Goto

[Chris Angelico]

On Sat, Dec 30, 2017 at 4:13 AM, bartc  wrote:
> If you want to translate code from one language to another, and the source
> language uses gotos, or uses control structures not available in the target
> language, then gotos would be very useful in the latter.
>

As has already been said in this thread, a competent FORTRAN
programmer can write FORTRAN code in any language. But if you want to
actually write Python code, instead of writing FORTRAN code that gets
run through a Python interpreter, you have to grok the Python way of
doing things. You can't do that by mechanically transforming source
code into the syntax of a different language.

People who try to tell you that all programming languages are
identical, just with different syntax, are doing you a disservice.
Lisp is not Python is not REXX is not C is not DeScribe Macro
Language. (Especially the latter. Do NOT try to write C code in DML.
It'll look ugly. Trust me.)

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Goto

[bartc]

On 29/12/2017 09:52, alister wrote:

On Thu, 28 Dec 2017 18:54:31 -0800, breamoreboy wrote:


On Thursday, December 28, 2017 at 7:40:14 PM UTC, alister wrote:

On Thu, 28 Dec 2017 00:58:48 -0200, Duram wrote:


How to use goto in python?

---
This email has been checked for viruses by AVG.
http://www.avg.com


Dont!
actually you cant - there isn't one*

*at least not in the core language no doubt some sick person will have
manager to hack together some sort of dodgy code to simulate it if you
look hard enough)



This http://entrian.com/goto/ has been around for almost 14 years.


ok ill admit i didn't look at all (because goto is a silly idea &
unnecessary)


If you want to translate code from one language to another, and the 
source language uses gotos, or uses control structures not available in 
the target language, then gotos would be very useful in the latter.


(gotos are frowned upon because they make program flow harder to see 
within a normal structured program. However examples of 'advanced' 
Python I've seen are such that I would rather contend with a few gotos.)


--
bartc
--
https://mail.python.org/mailman/listinfo/python-list

Re: Goto

[mm0fmf]

On 28/12/2017 22:38, Tim Chase wrote:

On 2017-12-29 08:42, Ben Finney wrote:

Duram  writes:


How to use goto in python?


Step 0: what is goto in Python?

Step 1: that's not something that exists in Python. So why are you
asking how to use something that doesn't exist?


so quick to shoot down a poor soul.

http://entrian.com/goto/

Gives you both GOTO and COMEFROM ;-)

-tkc




This! An awful lot of my early C++, C# and Python programs resembled 
FORTRAN66, it took effort to learn the Zen of each language. Now I can 
continue to write FORTRAN66 style programs in Python and unlearn all the 
good stuff.


Thank you. And remember, a good programmer can write FORTRAN66 programs 
in any language!

--
https://mail.python.org/mailman/listinfo/python-list

Re: Goto

[alister via Python-list]

On Thu, 28 Dec 2017 18:54:31 -0800, breamoreboy wrote:

> On Thursday, December 28, 2017 at 7:40:14 PM UTC, alister wrote:
>> On Thu, 28 Dec 2017 00:58:48 -0200, Duram wrote:
>> 
>> > How to use goto in python?
>> > 
>> > ---
>> > This email has been checked for viruses by AVG.
>> > http://www.avg.com
>> 
>> Dont!
>> actually you cant - there isn't one*
>> 
>> *at least not in the core language no doubt some sick person will have
>> manager to hack together some sort of dodgy code to simulate it if you
>> look hard enough)
>> 
>> 
> This http://entrian.com/goto/ has been around for almost 14 years.

ok ill admit i didn't look at all (because goto is a silly idea & 
unnecessary)



-- 
The sunlights differ, but there is only one darkness.
-- Ursula K. LeGuin, "The Dispossessed"
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Goto

[breamoreboy]

On Friday, December 29, 2017 at 3:28:23 AM UTC, Ben Finney wrote:
> Tim Chase writes:
> 
> > [third-party website]
> > Gives you […]
> 
> So, it's not in Python, it's a third-party (joke) package. Hence is
> probably not what Duram is asking about as “goto in Python”.
> 
> I'm still open to learning what Duram meant by “goto in Python”. Rather
> than everyone else piling on with suggestions, can we let Duram answer?
> 
> -- 
>  \  “Think for yourselves and let others enjoy the privilege to do |
>   `\  so too.” —Voltaire, _Essay On Tolerance_ |
> _o__)  |
> Ben Finney

Did you miss Tim's wink, which you've cut from your reply, or did you get out 
of bed on the wrong side this morning, or what?

--
Kindest regards.

Mark Lawrence.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Goto

[Ben Finney]

Tim Chase  writes:

> [third-party website]
> Gives you […]

So, it's not in Python, it's a third-party (joke) package. Hence is
probably not what Duram is asking about as “goto in Python”.

I'm still open to learning what Duram meant by “goto in Python”. Rather
than everyone else piling on with suggestions, can we let Duram answer?

-- 
 \  “Think for yourselves and let others enjoy the privilege to do |
  `\  so too.” —Voltaire, _Essay On Tolerance_ |
_o__)  |
Ben Finney

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Goto

[Tim Chase]

On 2017-12-29 08:42, Ben Finney wrote:
> Duram  writes:
> 
> > How to use goto in python?  
> 
> Step 0: what is goto in Python?
> 
> Step 1: that's not something that exists in Python. So why are you
> asking how to use something that doesn't exist?

so quick to shoot down a poor soul.

http://entrian.com/goto/

Gives you both GOTO and COMEFROM ;-)

-tkc




-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Goto

[breamoreboy]

On Thursday, December 28, 2017 at 7:40:14 PM UTC, alister wrote:
> On Thu, 28 Dec 2017 00:58:48 -0200, Duram wrote:
> 
> > How to use goto in python?
> > 
> > ---
> > This email has been checked for viruses by AVG.
> > http://www.avg.com
> 
> Dont!
> actually you cant - there isn't one*
> 
> *at least not in the core language no doubt some sick person will have 
> manager to hack together some sort of dodgy code to simulate it if you 
> look hard enough)
> 

This http://entrian.com/goto/ has been around for almost 14 years.

--
Kindest regards.

Mark Lawrence.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Goto

[Chris Angelico]

On Fri, Dec 29, 2017 at 11:17 AM, bartc  wrote:
> On 28/12/2017 21:42, Ben Finney wrote:
>>
>> Duram  writes:
>>
>>> How to use goto in python?
>>
>>
>> Step 0: what is goto in Python?
>>
>> Step 1: that's not something that exists in Python. So why are you
>> asking how to use something that doesn't exist?
>
>
> Goto exists in the form of the JUMP_ABSOLUTE byte-code.
>
> But it's not accessible from the language.
>

That's an implementation detail in one implementation of Python
(albeit the most popular one). It is not part of the language.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Goto

[Ben Finney]

bartc  writes:

> But it's not accessible from the language.

Another way to say that (and the way I said the same thing) is: It
doesn't exist in Python.

-- 
 \ “I went to the museum where they had all the heads and arms |
  `\  from the statues that are in all the other museums.” —Steven |
_o__)   Wright |
Ben Finney

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Goto

[bartc]

On 28/12/2017 21:42, Ben Finney wrote:

Duram  writes:


How to use goto in python?


Step 0: what is goto in Python?

Step 1: that's not something that exists in Python. So why are you
asking how to use something that doesn't exist?


Goto exists in the form of the JUMP_ABSOLUTE byte-code.

But it's not accessible from the language.


--
bartc


--
https://mail.python.org/mailman/listinfo/python-list

Re: Goto

[Ben Finney]

Duram  writes:

> How to use goto in python?

Step 0: what is goto in Python?

Step 1: that's not something that exists in Python. So why are you
asking how to use something that doesn't exist?

-- 
 \“[R]ightful liberty is unobstructed action, according to our |
  `\will, within limits drawn around us by the equal rights of |
_o__) others.” —Thomas Jefferson, 1819 |
Ben Finney

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Goto

[alister via Python-list]

On Thu, 28 Dec 2017 00:58:48 -0200, Duram wrote:

> How to use goto in python?
> 
> ---
> This email has been checked for viruses by AVG.
> http://www.avg.com

Dont!
actually you cant - there isn't one*

*at least not in the core language no doubt some sick person will have 
manager to hack together some sort of dodgy code to simulate it if you 
look hard enough)



-- 
Bigmac's brother was reliably believed to be in the job of moving video
recorders around in an informal way.
(Only You Can Save Mankind)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: "Goto" statement in Python

[Chris Angelico]

On Sun, Apr 16, 2017 at 5:21 PM, Mikhail V  wrote:
> I am in the category "I just want to express some
> algorithm and don't want to learn every year new concepts".
> I tend to think that extremely restricted syntax, in the sence
> of having only few flow control instructions actually helps with
> readability, despite I have never seriously used other languages
> than python so I cannot judge GOTO specifically.
> [...]
> Seriously, when I open some random .py file from the web
> and everywhere see class, class, class, kilometers of indentation...
> Hair around one-liners all over the files.
> And hedgehogs of try: except blocks, well, this is
> straining, and trying to learn why I need
> some of those, multiplies the pain.
> So your comment applies to me too and I must sound
> like an old stupid man I suppose?

You sound more like someone who's never grown beyond a one-man
project. Most of us understand code primarily as a tool for
communicating between humans, and secondarily for the computer to
execute. And you most definitely sound like someone who thinks in the
concrete, not in the abstract. These constructs are to express human
concepts, even though they take a lot of low-level tools to make them
up.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: "Goto" statement in Python

[Mikhail V]

On 14 April 2017 at 03:44, Steve D'Aprano  wrote:
> On Fri, 14 Apr 2017 12:52 am, bartc wrote:
>
>> I know this isn't the Python need-for-speed thread, but this is a
>> classic example where the lack of one simple feature leads to using
>> slower, more cumbersome ones.
>
> Dear gods, have I fallen back in time to 1975 again?
>

Everything new is definitely better, right?

> Are there reasonable uses for GOTO? Perhaps. There are semi-structured
> restricted versions of GOTO, like exceptions, break and return, but an
> unrestricted GOTO where you can jump anywhere in the program is a terrible
> feature

Yes I suppose, but I know too little about who restricts or
allows and how. And in python it is allowed to mistype
for example "while True :" in any part of the
.py file, as well as one can accidentally mess up with
indentation.
But indeed, Python has very restricted syntax and it is very good.


> Even that's not enough for some. Donald Knuth, who supports the use of GOTO
> under some circumstances, maintains that any program using GOTOs should
> have the invariant that its flow chart can be drawn with all forward
> branches on the left, all backward branches on the right, and no branches
> crossing each other.

I am in the category "I just want to express some
algorithm and don't want to learn every year new concepts".
I tend to think that extremely restricted syntax, in the sence
of having only few flow control instructions actually helps with
readability, despite I have never seriously used other languages
than python so I cannot judge GOTO specifically.

But that comes to many other aspects, most of the time
I just want my code look consistent and readable
and this is more representational problem.
And I suppose that with Python, what bothers
me is  zig-zags of indentation.

Now regardless of Python :
if I would have, say 2 forms of GOTO,
ie direct GOTO and e.g. 'loop' ,

an improvised pseudocode example:

"""
in_menu = true

SUB -
 init some
 draw thing

 # if skip_scan : goto .x

loop
|K=readkey()
|if  K[shift] :
|goto .1
|if  K[m] :
|in_menu = false
|goto .1
|if  K[o] :
|in_menu = false
|.1  make something
|make something
|if (in_menu = false) : goto .x
\__

.x
 clean_up something
 clean_up something

"""

or a classic:

x, y = 0
xx, yy = 300

loop
|loop
||
||   x = x + 1
||   if (x+y) > 100 : goto .x
||   if (x>xx) : goto .1
|\__
|
|.1
|y = y + 1
|if (x>xx) : goto .x
\__

.x

"""

So with 'else'-less condition statement, goto, and loop
construct I would have simpler representation simply because
I would have no 'else', for(), etc... And I'd avoid nested loops as much
as i can.
So less indentation zig-zags and plain "column" code look everywhere,
I think that is what many programmers are looking for.
Just from the reader's POV: having implicit labels for exiting loop
is IMO not worse than additional keywords e.g. "break"...
At least I would not be so fast to judge that.
It is just the question, *how would I input and edit such code*
to avoids typos and renaming labels.


[...]
>> (** Although I find code full of class definitions, one-liners, decorators
>> and all the other esoterics, incomprehensive. I'm sure I'm not the only
>> one, so perhaps readability isn't too much of a priority either.)

>Classes and decorators are not esoteric. You sound like an old man who
>complains about this new-fangled "telephone", and how things were so much
>better when we had messenger boys to deliver messages anywhere in the city.

Seriously, when I open some random .py file from the web
and everywhere see class, class, class, kilometers of indentation...
Hair around one-liners all over the files.
And hedgehogs of try: except blocks, well, this is
straining, and trying to learn why I need
some of those, multiplies the pain.
So your comment applies to me too and I must sound
like an old stupid man I suppose?
And I don't like new "telephones" - they are heavy, need charge
every 2 day, does not fit in the hand well, and just to repat
the last call I need to swipe the stupid touch screen.


Mikhail
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Goto Considered Harmful [was Re: Python and the need for speed]

[Gregory Ewing]

Dennis Lee Bieber wrote:

And since the original COBOL standard numeric format was BCD, PIC not
only defined output layout, but also internal storage needed by numerics
and string data types.


Unless you said USAGE IS COMPUTATIONAL, which left the compiler
free to pick a more efficient storage format internally.

BTW, one thing I think COBOL did right was not limiting you
to some arbitrary compiler or language defined maximum size
for numbers. You could declare something as PIC 9(100) and
do arithmetic on 100-digit numbers if you wanted. (At least
potentially -- not sure if all compilers would really
support something that big.)

--
Greg
--
https://mail.python.org/mailman/listinfo/python-list

Re: Goto Considered Harmful [was Re: Python and the need for speed]

[Marko Rauhamaa]

r...@zedat.fu-berlin.de (Stefan Ram):

> struct example
> { PIC<5,X<15>> last_name; 
>   PIC<88,VALUE<1,3,5,7,9>> odd_numbers; }
>
>   . The above assumes appropriate definitions for »VALUE« (as a
>   variadic template) »PIC«, and »X«. Only a C++ expert would be able
>   to provide these definitions, but then they could be used by average
>   C++ programmers.

I don't like your expert/average dichotomy. Similar dichotomies plague
other frameworks: Eclipse, Jenkins, Maven, Xt, MS Word etc.

If templates are considered a good thing, creating them should be
considered routine for *all* C++ programmers.

>   . C++ has a very expressive user-definable type system including
>   user-definable literals.

I don't like said system. Analogously, I'm not too keen on formal
schemata. Even more generally, I'm not big on *rule languages*, which
are ad-hoc and incomplete. Instead, I prefer *programming languages*,
which are compact and expressive, or even plain English.

>   It should then also be possible to generate compile-time errors for
>   assignments such as
>
> example_instance.odd_numbers = 4;

Every programming language has its big selling points. C++'s gospel is
its utmost compile-time checking. I'm a long time user of C++, but I'm
not a convert to that ideology.

>   . I know too little about Python to tell whether something like this
>   would be possible with Python, too.

Unfortunately, Python is taking baby steps in that direction.


Marko
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: "Goto" statement in Python

[Rob Gaddi]

On 04/14/2017 07:19 AM, Dennis Lee Bieber wrote:

On Fri, 14 Apr 2017 11:44:59 +1000, Steve D'Aprano
 declaimed the following:



Even that's not enough for some. Donald Knuth, who supports the use of GOTO
under some circumstances, maintains that any program using GOTOs should
have the invariant that its flow chart can be drawn with all forward
branches on the left, all backward branches on the right, and no branches
crossing each other.



Good thing I never had him for an instructor... My practice, when last
flow-charting, favored back-branches on the left.

After all, I read left-to-right/top-to-bottom, so forward branches
going right and down seem natural. Encountering a branch going left sort of
implies "re-reading" part of the chart; going upwards...



Yeah, but I love the naked concept there.  It pretty much encapsulates 
what I find to be the only useful use of GOTO in any reasonable language 
in a simple, easy to visualize way.  If your GOTOs are crossing you've 
done something wrong.


If more people had good mechanisms for visualizing their code I'd use 
far less profanity literally every day of my life.


--
Rob Gaddi, Highland Technology -- www.highlandtechnology.com
Email address domain is currently out of order.  See above to fix.
--
https://mail.python.org/mailman/listinfo/python-list

Re: "Goto" statement in Python

[Chris Angelico]

On Sat, Apr 15, 2017 at 12:13 AM, Dennis Lee Bieber
 wrote:
> On Thu, 13 Apr 2017 18:36:57 -0600, Ian Kelly 
> declaimed the following:
>
>>
>>Well, you can do it in Assembly. And BASIC, if you count the primitive
>>GOSUB-type subroutines, though modern BASICs have real subroutines
>>that don't allow it.
>>
> REXX probably allows it too... (No GOTO, but the SIGNAL statement can
> do unconditional jumps to named labels)... Hmmm, if I read the manual
> correctly, any use of SIGNAL will terminate loops, even if the SIGNAL and
> target are both within the same loop.

This is correct. Annoyingly, it also wipes out indentation in the
TRACE output, so you really want to use it *only* for error handling
(which is its stated purpose).

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: "Goto" statement in Python

[Chris Green]

Bernd Nawothnig  wrote:
> On 2017-04-13, Mikhail V wrote:
> > On 13 April 2017 at 18:48, Ian Kelly  wrote:
> >> On Thu, Apr 13, 2017 at 10:23 AM, Mikhail V  wrote:
> >>> Now I wonder, have we already collected *all* bells and whistles of Python
> >>> in these two examples, or is there something else for expressing trivial 
> >>> thing.
> >>
> >> Functions and exceptions are considered "bells and whistles"?
> >
> > You mean probably classes and exceptions? For me, indeed they are,
> > but it depends.
> >
> > And breaking the code into def() chunks that are not
> > functions but just chunks... I don't know, looks bad.
> 
> Organising code in a bunch of small functions is by far better coding
> style and better readable than put it all together in one chunk. And
> that holds for all programming languages, not only for Python.
> 
The functions need *some* reason for being an entity though.

-- 
Chris Green
·
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: "Goto" statement in Python

[Bernd Nawothnig]

On 2017-04-13, Grant Edwards wrote:
> On 2017-04-13, Rob Gaddi  wrote:
>
>> No, C doesn't support exception handling.  As a result, handling error 
>> conditions in C is a huge pain for which (forward-only) goto is often, 
>> while not the only remedy, the least painful one.
>
> Indeed. That is almost the only place I use 'goto' in C, and the
> almost the only place I see others use it.  Very occasionally, you see
> a the error handling goto refactored into a backwards "goto retry":
>
> this code
>
> foo()
>   {
>   while (1)
> {
>   
>   if ()
>goto error:
>   
>   return;
>
> error:
>   
> }
>   }

foo()
  {
  int done = 0;
  while (! done)
{
  
  if () {

  } else {
done = 1;

 }
  }




Bernd

-- 
Die Antisemiten vergeben es den Juden nicht, dass die Juden ‘Geist’
haben – und Geld. Die Antisemiten – ein Name der
‘Schlechtweggekommenenen’ [Friedrich Nietzsche]
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: "Goto" statement in Python

[Bernd Nawothnig]

On 2017-04-13, Mikhail V wrote:
> On 13 April 2017 at 18:48, Ian Kelly  wrote:
>> On Thu, Apr 13, 2017 at 10:23 AM, Mikhail V  wrote:
>>> Now I wonder, have we already collected *all* bells and whistles of Python
>>> in these two examples, or is there something else for expressing trivial 
>>> thing.
>>
>> Functions and exceptions are considered "bells and whistles"?
>
> You mean probably classes and exceptions? For me, indeed they are,
> but it depends.
>
> And breaking the code into def() chunks that are not
> functions but just chunks... I don't know, looks bad.

Organising code in a bunch of small functions is by far better coding
style and better readable than put it all together in one chunk. And
that holds for all programming languages, not only for Python.



Bernd

-- 
Die Antisemiten vergeben es den Juden nicht, dass die Juden ‘Geist’
haben – und Geld. Die Antisemiten – ein Name der
‘Schlechtweggekommenenen’ [Friedrich Nietzsche]
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: "Goto" statement in Python

[bartc]

On 14/04/2017 02:44, Steve D'Aprano wrote:

On Fri, 14 Apr 2017 12:52 am, bartc wrote:


I know this isn't the Python need-for-speed thread, but this is a
classic example where the lack of one simple feature leads to using
slower, more cumbersome ones.


Dear gods, have I fallen back in time to 1975 again?

The Goto Wars are over, and the structured programming camp won the war
decisively.

Are functions/procedures *technically* slower than GOTOs? Yes. So what?
You're nano-optimizing the wrong thing: you're saving a microsecond of
runtime at the cost of a megasecond of development and maintenance time.


Usually, yes. (And when you run CPython, whatever speed you do get, is 
partly thanks to compiler writers choosing jumps, or in-lining, over 
function calls. All those nanoseconds add up.)


However my comment wasn't specifically about goto. It's about using a 
slower feature to get around the lack of another feature that could have 
been implemented efficiently.



Function calls, returns and generators are rather more heavyweight in
comparison.


And enormously better.


It depends if your application is speed-sensitive. Much scripting code 
isn't, or if it is, most of the work is done outside the language.


But sometimes you want your dynamic code to do some actual work of its 
own that involves executing byte-code, rather than calling some compiled 
code. And performance can matter.


--
bartc
--
https://mail.python.org/mailman/listinfo/python-list

Re: Goto Considered Harmful [was Re: Python and the need for speed]

[Marko Rauhamaa]

Gregory Ewing :

> Steve D'Aprano wrote:
>
>> If PIC is so great, why do no other languages have it?
>
> Something akin to it has turned up in other places, although usually
> in the guise of an output formatting facility rather than a way of
> describing how data is stored internally. For example, the PRINT USING
> found in some BASIC dialects.

You have the storage thing in SQL:

CHAR(4)
VARCHAR(256)
YEAR(2)
DECIMAL(5,2)


Marko
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Goto Considered Harmful [was Re: Python and the need for speed]

[Gregory Ewing]

Ian Kelly wrote:

Yikes. I never took the time to learn COBOL, but that almost sounds
like something that you'd find in an esoteric language like INTERCAL.


COBOL has other fun stuff like that, too. For example, the
destination of a GOTO statement can be changed from elsewhere
in the program:

https://www.ibm.com/support/knowledgecenter/SSAE4W_7.1.0/com.ibm.etools.iseries.langref.doc/c0925395347.htm

Not quite COMEFROM, but it's getting close!

--
Greg
--
https://mail.python.org/mailman/listinfo/python-list

Re: Goto Considered Harmful [was Re: Python and the need for speed]

[Gregory Ewing]

Steve D'Aprano wrote:


If PIC is so great, why do no other languages have it?


Something akin to it has turned up in other places, although
usually in the guise of an output formatting facility rather
than a way of describing how data is stored internally.
For example, the PRINT USING found in some BASIC dialects.

--
Greg
--
https://mail.python.org/mailman/listinfo/python-list

Re: "Goto" statement in Python

[Rustom Mody]

On Friday, April 14, 2017 at 7:15:11 AM UTC+5:30, Steve D'Aprano wrote:
> On Fri, 14 Apr 2017 12:52 am, bartc wrote:
> 
> > I know this isn't the Python need-for-speed thread, but this is a
> > classic example where the lack of one simple feature leads to using
> > slower, more cumbersome ones.
> 
> Dear gods, have I fallen back in time to 1975 again?

Good that you start with the suggestion that we are not in 1975



> Features should not be judged solely on their usefulness to the best 1% of
> programmers using the feature in the best possible way. You also need to
> consider the lesser mortals, the below-average 50% of programmers who will
> use the feature in sub-optimal if not outright terrible ways.
> 
> GOTOs are far to easy to abuse. The harm that they do is outweighed a
> thousand times by the rare positive use. Most languages do well to avoid
> GOTO, even if that means that there are one or two rare uses that have to
> be written slightly sub-optimally for the lack.

That sounds very 1970s to me.

With the languages that I (and presumably you) grew up with using gotos was
too easy; not using was hard or impossible.
The most structured was Pascal which set out to be ornery by making one declare
labels. With everything else — Fortran-IV, Basic, assembler — it was next to 
impossible.

Cut to 2017 and take a random 20 year old brought up on 
python/java/ruby/javascript/haskell

Where/how would he have learnt to use gotos?

In short: In 1968 "Goto statement considered harmful" was a necessary viewpoint.
Today its a quasi-religious bias without basis.

Personal Note: Much of the direction that my programming/teaching has taken in
the last 30 years can be traced to a statement made by a teacher when I was 
graduating:

“What the goto does to control-structure, the assignment does to data-structure”
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Goto Considered Harmful [was Re: Python and the need for speed]

[Rustom Mody]

On Friday, April 14, 2017 at 7:03:24 AM UTC+5:30, Steve D'Aprano wrote:
> On Fri, 14 Apr 2017 04:09 am, Rustom Mody wrote:

> > [Sorry its a vague memory of something I read more than a decade ago that
> > [I cant
> > trace again]
> > Some unknown Cobol programmer talking about Dijkstra:
> > 
> > Dijkstra used his enormous prestige to destroy Cobol.
> > We lost a great deal
> > What did he gain?
> > Ok so Cobol's control constructs are below par
> > But do any of its modern successors have its data-describing properties?
> > [the PIC clause]
> 
> If PIC is so great, why do no other languages have it?
> 
> That's a serious question, not a rhetorical question.

Dunno enough about Cobol and that ecosystem to make a useful comment
However your question is really two:
1. Whats good about Cobol's PIC?
2. Why dont other languages have it/that benefit?

1st as I said I dont feel qualified to answer
2nd is ridiculous. Because of collective stupidity:
- Species go extinct
- Garbage fills the oceans
- Fukushima fallout reaches Canada
- And in general good, valuable things die out
> 
> "Imminent Death Of Cobol Predicted. Again."
> 
> When the sun finally expands into a supergiant in five billion years,
> destroying the earth, the last survivors to die will be COBOL-programming
> cockroaches and Keith Richards.

> > Maybe that's a response to similar violent, unnecessary barbs from
> > Dijkstra?
> 
> "Violent"?
> 
> Are you one of those people who think that calling a person an idiot is
> morally indistinguishable from beating them into a coma?
> 
> "Sticks and stones will break my bones, but that's nothing to the harm
> caused by a few mean words."

You are treating violence as literal physical violence.
Thats backwards. Ultimately all violence is moral
Else an orthopaedic sawing off a knee to replace or a dentist yanking out a 
molar would be felons
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: "Goto" statement in Python

[Steve D'Aprano]

On Fri, 14 Apr 2017 12:52 am, bartc wrote:

> I know this isn't the Python need-for-speed thread, but this is a
> classic example where the lack of one simple feature leads to using
> slower, more cumbersome ones.

Dear gods, have I fallen back in time to 1975 again?

The Goto Wars are over, and the structured programming camp won the war
decisively.

Are functions/procedures *technically* slower than GOTOs? Yes. So what?
You're nano-optimizing the wrong thing: you're saving a microsecond of
runtime at the cost of a megasecond of development and maintenance time.

At the point that you say "Function calls ... are rather more heavyweight"
the whole argument becomes farcical. Function calls are so prevalent in
modern structured programming (whether you write in procedural, functional
or object-oriented style, or a combination of all three) that saving one or
two function calls isn't even a micro-optimization, especially not in a
high-level language.

To save any meaningful time, you would need to return to the bad-old-days of
unmaintainable unstructured spaghetti code.

This debate about the usefulness of GOTO in modern languages reminds me of
the sort of people who will drive around the city for an hour looking to
save 0.1 cent on the cost of petrol (gasoline for Americans).


> 'goto' would be one easy-to-execute byte-code; no variables, objects or
> types to worry about. If implemented properly (with the byte-code
> compiler using a dedicated name-space for labels) there would be no name
> lookups.

I don't care much about the implementation of GOTO. I care a lot about the
code written that includes GOTOs.

Are there reasonable uses for GOTO? Perhaps. There are semi-structured
restricted versions of GOTO, like exceptions, break and return, but an
unrestricted GOTO where you can jump anywhere in the program is a terrible
feature for anything but the smallest, most trivial programs. To be even
*close* to safe, you have to restrict GOTO considerably. At the very
minimum, you need two restrictions:

- cannot jump into the middle of a procedure or function;

- cannot jump immediately out of a procedure or function without 
  cleaning up the stack and other handling.


Even that's not enough for some. Donald Knuth, who supports the use of GOTO
under some circumstances, maintains that any program using GOTOs should
have the invariant that its flow chart can be drawn with all forward
branches on the left, all backward branches on the right, and no branches
crossing each other.

Features should not be judged solely on their usefulness to the best 1% of
programmers using the feature in the best possible way. You also need to
consider the lesser mortals, the below-average 50% of programmers who will
use the feature in sub-optimal if not outright terrible ways.

GOTOs are far to easy to abuse. The harm that they do is outweighed a
thousand times by the rare positive use. Most languages do well to avoid
GOTO, even if that means that there are one or two rare uses that have to
be written slightly sub-optimally for the lack.


> Function calls, returns and generators are rather more heavyweight in
> comparison.

And enormously better.




-- 
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Goto Considered Harmful [was Re: Python and the need for speed]

[Steve D'Aprano]

On Fri, 14 Apr 2017 04:09 am, Rustom Mody wrote:

> On Thursday, April 13, 2017 at 11:14:15 PM UTC+5:30, Steve D'Aprano wrote:
>> Meyer's "Considered Harmful Essays Considered Harmful" essay is
>> hypocritical junk, and should be considered harmful.
> 
> Your view.

Well duh :-)


> Here's an alternative.
> [Sorry its a vague memory of something I read more than a decade ago that
> [I cant
> trace again]
> Some unknown Cobol programmer talking about Dijkstra:
> 
> Dijkstra used his enormous prestige to destroy Cobol.

"Imminent Death Of Cobol Predicted. Again."

When the sun finally expands into a supergiant in five billion years,
destroying the earth, the last survivors to die will be COBOL-programming
cockroaches and Keith Richards.


> We lost a great deal
> What did he gain?
> Ok so Cobol's control constructs are below par
> But do any of its modern successors have its data-describing properties?
> [the PIC clause]

If PIC is so great, why do no other languages have it?

That's a serious question, not a rhetorical question.



> Or consider(!) Alan Kay's statement: "Arrogance in computer science is
> measured in nanodijktras"

Indeed. What's your point? Because that sounds awfully like an ad hominem
fallacy. Dijkstra was arrogant, therefore he must be wrong.


> Maybe that's a response to similar violent, unnecessary barbs from
> Dijkstra?

"Violent"?

Are you one of those people who think that calling a person an idiot is
morally indistinguishable from beating them into a coma?

"Sticks and stones will break my bones, but that's nothing to the harm
caused by a few mean words."




-- 
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Goto Considered Harmful [was Re: Python and the need for speed]

[Ian Kelly]

On Thu, Apr 13, 2017 at 12:51 PM, Nathan Ernst  wrote:
> Thank you for that Alan Kay quote. Brightened up my day. Since you also
> mentioned COBOL, and this is a thread about "goto", reminded me of the
> single most abhorrent thing I ever saw in COBOL (I had to convert a single
> COBOL batch process to ASP.Net as an intern back in 2003-4). "MOVE NEXT
> SENTENCE". What is this statement? An unlabelled goto. It literally jumps
> to the next period: "." in the source.
>
> Now, I'm fine with judicious use of goto with good labels. (and, I've only
> used goto maybe 3 or 4 times in a 15 year career), but a blocky construct
> like "MOVE NEXT SENTENCE" in a language that also has lots of (all-caps
> required) block statements to jump to a tiny on the screen period...that is
> just evil.

Yikes. I never took the time to learn COBOL, but that almost sounds
like something that you'd find in an esoteric language like INTERCAL.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: "Goto" statement in Python

[Ian Kelly]

On Thu, Apr 13, 2017 at 4:59 PM, bartc  wrote:
> On 13/04/2017 22:58, Ian Kelly wrote:
>>
>> On Thu, Apr 13, 2017 at 3:27 PM, Dennis Lee Bieber
>>  wrote:
>>>
>>> On Thu, 13 Apr 2017 15:52:24 +0100, bartc  declaimed the
>>> following:
>>>
 'goto' would be one easy-to-execute byte-code; no variables, objects or
 types to worry about. If implemented properly (with the byte-code
 compiler using a dedicated name-space for labels) there would be no name
 lookups.

>>>
>>> Only if GOTO is not allowed to break out of namespaces...
>>>
>>> NO GOTO from inside a function to some global catch-all
>>> handler...
>
>
> (That doesn't happen. No sane language would allow it, not on the user-side
> anyway.)

Well, you can do it in Assembly. And BASIC, if you count the primitive
GOSUB-type subroutines, though modern BASICs have real subroutines
that don't allow it.

>>> Once you permit uncontrolled/unlimited GOTO you have to be
>>> concerned
>>> with stack-frames and object life-times.
>>
>>
>> Even within a function you would still have to be concerned about a
>> goto from inside a try or with block to outside of that block, as the
>> finally block or the context manager's __exit__ still need to be
>> executed on the way out.
>
>
> So how does 'break' manage it? I assume break works from inside a try- or
> with-block.

Yes, it would have to work similarly to break, continue and return. I
didn't mean to imply that it was impossible, only that it's not quite
as simple as just modifying a program counter.

For reference, here's what break inside a try block compiles to:

>>> dis.dis("""
... while True:
... try:
... break
... finally:
... print("Bye")
... """)
  2   0 SETUP_LOOP  22 (to 24)

  3 >>2 SETUP_FINALLY6 (to 10)

  4   4 BREAK_LOOP
  6 POP_BLOCK
  8 LOAD_CONST   0 (None)

  6 >>   10 LOAD_NAME0 (print)
 12 LOAD_CONST   1 ('Bye')
 14 CALL_FUNCTION1
 16 POP_TOP
 18 END_FINALLY
 20 JUMP_ABSOLUTE2
 22 POP_BLOCK
>>   24 LOAD_CONST   0 (None)
 26 RETURN_VALUE
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: "Goto" statement in Python

[bartc]

On 13/04/2017 22:58, Ian Kelly wrote:

On Thu, Apr 13, 2017 at 3:27 PM, Dennis Lee Bieber
 wrote:

On Thu, 13 Apr 2017 15:52:24 +0100, bartc  declaimed the
following:


'goto' would be one easy-to-execute byte-code; no variables, objects or
types to worry about. If implemented properly (with the byte-code
compiler using a dedicated name-space for labels) there would be no name
lookups.



Only if GOTO is not allowed to break out of namespaces...

NO GOTO from inside a function to some global catch-all handler...


(That doesn't happen. No sane language would allow it, not on the 
user-side anyway.)



Once you permit uncontrolled/unlimited GOTO you have to be concerned
with stack-frames and object life-times.


Even within a function you would still have to be concerned about a
goto from inside a try or with block to outside of that block, as the
finally block or the context manager's __exit__ still need to be
executed on the way out.


So how does 'break' manage it? I assume break works from inside a try- 
or with-block.


Jumping /into/ such a block might be more tricky, but it is simple 
enough to not allow it.


--
Bartc
--
https://mail.python.org/mailman/listinfo/python-list

Re: "Goto" statement in Python

[Ian Kelly]

On Thu, Apr 13, 2017 at 3:27 PM, Dennis Lee Bieber
 wrote:
> On Thu, 13 Apr 2017 15:52:24 +0100, bartc  declaimed the
> following:
>
>>'goto' would be one easy-to-execute byte-code; no variables, objects or
>>types to worry about. If implemented properly (with the byte-code
>>compiler using a dedicated name-space for labels) there would be no name
>>lookups.
>>
>
> Only if GOTO is not allowed to break out of namespaces...
>
> NO GOTO from inside a function to some global catch-all handler... No
> GOTO from a global scope into a non-global scope.
>
> Once you permit uncontrolled/unlimited GOTO you have to be concerned
> with stack-frames and object life-times.

Even within a function you would still have to be concerned about a
goto from inside a try or with block to outside of that block, as the
finally block or the context manager's __exit__ still need to be
executed on the way out.

Not to mention the time-honored tradition of using goto to jump INTO a
block, such as Duff's Device.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: "Goto" statement in Python

[Marko Rauhamaa]

Rob Gaddi :

> On 04/13/2017 08:26 AM, Marko Rauhamaa wrote:
>> I have occasionally felt the urge to try "goto" in my C code, but having
>> written it, I have taken it out. It just doesn't make the code look more
>> elegant or robust. Unlike "break" or "return," "goto" makes me uneasy
>> about variable scope and lifetime.
> [...]
> You see it all the time in kernel code or when doing I/O.  A pretty
> common pattern is:
>
>   int return_val = 1;
>   if (init_thing(x)) goto bk1;
>   if (init_thing(y)) goto bk2;
>   if (init_thing(z)) goto bk3;
>
>   do_things_with(x, y, z);
>   return_val = 0;
>
>   bk3:  cleanup_thing(z);
>   bk2:  cleanup_thing(y);
>   bk1:  cleanup_thing(x);
>   return return_val;

I know, but I still don't like it.


Marko
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Goto Considered Harmful [was Re: Python and the need for speed]

[Nathan Ernst]

Thank you for that Alan Kay quote. Brightened up my day. Since you also
mentioned COBOL, and this is a thread about "goto", reminded me of the
single most abhorrent thing I ever saw in COBOL (I had to convert a single
COBOL batch process to ASP.Net as an intern back in 2003-4). "MOVE NEXT
SENTENCE". What is this statement? An unlabelled goto. It literally jumps
to the next period: "." in the source.

Now, I'm fine with judicious use of goto with good labels. (and, I've only
used goto maybe 3 or 4 times in a 15 year career), but a blocky construct
like "MOVE NEXT SENTENCE" in a language that also has lots of (all-caps
required) block statements to jump to a tiny on the screen period...that is
just evil.

On Thu, Apr 13, 2017 at 1:09 PM, Rustom Mody  wrote:

> On Thursday, April 13, 2017 at 11:14:15 PM UTC+5:30, Steve D'Aprano wrote:
> > Meyer's "Considered Harmful Essays Considered Harmful" essay is
> hypocritical
> > junk, and should be considered harmful.
>
> Your view.
> Here's an alternative.
> [Sorry its a vague memory of something I read more than a decade ago that
> I cant
> trace again]
> Some unknown Cobol programmer talking about Dijkstra:
>
> Dijkstra used his enormous prestige to destroy Cobol.
> We lost a great deal
> What did he gain?
> Ok so Cobol's control constructs are below par
> But do any of its modern successors have its data-describing properties?
> [the PIC clause]
>
> Or consider(!) Alan Kay's statement: "Arrogance in computer science is
> measured
> in nanodijktras"
> Maybe that's a response to similar violent, unnecessary barbs from
> Dijkstra?
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: "Goto" statement in Python

[Grant Edwards]

On 2017-04-13, Rob Gaddi  wrote:

> No, C doesn't support exception handling.  As a result, handling error 
> conditions in C is a huge pain for which (forward-only) goto is often, 
> while not the only remedy, the least painful one.

Indeed. That is almost the only place I use 'goto' in C, and the
almost the only place I see others use it.  Very occasionally, you see
a the error handling goto refactored into a backwards "goto retry":

this code

foo()
  {
  while (1)
{
  
  if ()
   goto error:
  
  return;

error:
  
}
  }

becomes

  foo()
  {
retry:
  
  if ()
{
   
   goto retry:
}
  
  }

I happen to find the latter easier to read.

Fortunately, Python doesn't need goto to deal with things like that.

> Or if you've really developed a need for self-harm, setjmp/longjmp.

I've tried to use setjmp/longjmp for error handling a few times.  It
never went well...

-- 
Grant Edwards   grant.b.edwardsYow! Catsup and Mustard all
  at   over the place!  It's the
  gmail.comHuman Hamburger!

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Goto Considered Harmful [was Re: Python and the need for speed]

[Larry Martell]

On Thu, Apr 13, 2017 at 2:09 PM, Rustom Mody  wrote:
> Or consider(!) Alan Kay's statement: "Arrogance in computer science is 
> measured
> in nanodijktras"

Completely unrelated but it reminded me about this bon mot about Niklaus Wirth:

Europeans tend to pronounce his name properly, as Nih-klaus Virt,
while Americans usually mangle it into something like Nickles Worth.
That has led to the programmer joke saying Europeans call him by name
while Americans call him by value.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Goto Considered Harmful [was Re: Python and the need for speed]

[Rustom Mody]

On Thursday, April 13, 2017 at 11:14:15 PM UTC+5:30, Steve D'Aprano wrote:
> Meyer's "Considered Harmful Essays Considered Harmful" essay is hypocritical
> junk, and should be considered harmful.

Your view.
Here's an alternative.
[Sorry its a vague memory of something I read more than a decade ago that I cant
trace again]
Some unknown Cobol programmer talking about Dijkstra:

Dijkstra used his enormous prestige to destroy Cobol.
We lost a great deal
What did he gain?
Ok so Cobol's control constructs are below par
But do any of its modern successors have its data-describing properties?
[the PIC clause]

Or consider(!) Alan Kay's statement: "Arrogance in computer science is measured
in nanodijktras" 
Maybe that's a response to similar violent, unnecessary barbs from Dijkstra?
-- 
https://mail.python.org/mailman/listinfo/python-list