Re: goto considered helpful (Was: question about linker)

Michael S <already5chosen@yahoo.com> writes:

On Fri, 20 Dec 2024 13:52:13 +0100
Rosario19 <Ros@invalid.invalid> wrote:
>

On Thu, 12 Dec 2024 14:44:54 +0200, Michael S  wrote:
>

On Wed, 11 Dec 2024 17:27:53 -0800
Keith Thompson > wrote:
>

bart > writes:
[...]
>

My experience of multi-level break is that there are two
main use-cases:
>
 * Used in the current loop only (not necessarily the
   innermost to an observer).  This is the most common
>
 * Used to exit the outermost loop
>
So to support these, named or even numbered loops are not
necessary.  (Eg.  I use 'exit' or 'exit all'.)

>
I would oppose a change to C that only applied to innermost and
outermost loops.  For one thing, I'm not aware of any other
language that does this (except perhaps your unnamed one).  For
another, it's easy enough to define a feature that handles any
arbitrary nesting levels, by applying names (labels) to loops.

>
The better solution is education.
Convince teachers in unis and colleges that goto is *not*
considered harmful for this particular use case.  Convince them
to teach that

I don't agree with this strategy.  More explanation below.

goto is not harmful in every case, if the people that write it,
indent that goto significally and have clear in mind and in the
text, what that goto has to do

>
I don't agree.  Many sorts of goto are hard to understand for the
reader even when they are crystal clear to the writer [at the
moment of writing].
That applies to nearly all forward gotos into block and to nearly
all backward gotos.  That is, there exists one sort of backward
goto that I find sufficiently understandable, but right now I am
unable to formalize its exact properties.
>
Of course, nothing of said above is relevant in context of gotos
that exit inner loops.

In my view using goto should always be done on a case-by-case basis
and not under any general rule.  More specifically, when first
writing a function it should be written without using goto (which is
always possible).  If something about the code feels off, write it
another way, still without using goto.  Continue re-writing in this
way as long as the results are dissatisfying, up to perhaps four or
five versions (in some cases I have done a lot more than that).  In
many cases function bodies start off too large, and the code can be
simplified and clarified by breaking a function into several smaller
sub-functions;  doing that often removes any sense that goto is
needed.

After making multiple attempts, if none of the alternatives reaches
a suitable subjective quality assessment, then trying writing a
version with goto (or perhaps several versions, depending on other
factors).  If the best using-goto version is judged better than the
best non-goto version, then use it;  otherwise use the best non-goto
version.

I might add that I do end up using goto (rarely) in various unusual
circumstances, and some of those uses are truly horrific.  I am
content that they are appropriate because the non-goto versions
tried have all been worse along one or more axes.

At large, Dijkstra is more right than wrong.

In my reading Dijkstra's point is not that goto should be avoided
but that teaching goto should be avoided:  student who learn to
write code using goto tend to produce tangled messes, at least more
than do those who are taught to use structured patterns of control
and not taught to use goto.  Reportedly Dijkstra has said that he is
not dogmatic about avoiding the use of goto, but it's important also
to understand the original point:  using goto should never be the
first line of defense, and education should reinforce that aphorism.