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