What I like about my "garbage language":
since 2011 it is "my garbage language";
I can add new control statements to it and thus eliminate the need for gotos
most of the time, because the old use cases of goto now have new solutions
(similar to C). And for many other needs like string handling, File I/O
etc., it is (for me)
far superior than other languages at hand (of course, due to extensions
I made
in the last 10 years).
It now has more features than IBMs Pascal/VS had, and it is portable
across platforms
(the P-Code generated on one platform will execute on the other)
and I will continue to extend it, as soon as I have more time to do so.
Ok: maybe it has more bugs than Pascal/VS, but if someone of the user
community
tells me about serious bugs, I will try to fix them.
BTW: extending GOTO to allow identifiers as targets is not on my ToDo list
(at the moment).
Kind regards
Bernd
Am 26.09.2022 um 02:38 schrieb David Crayford:
According to Linus you’ve been brainwashed by using a garbage language
https://koblents.com/Ches/Links/Month-Mar-2013/20-Using-Goto-in-Linux-Kernel-Code/
On 26 Sep 2022, at 1:43 am, Bernd Oppolzer <bernd.oppol...@t-online.de> wrote:
I try to be not dogmatic about GOTO statements,
in fact, I am coding COBOL in my money (everyday) job, and there are lots of GO
TOs around;
I try to remove them, when I do larger refactoring, but if not, I leave them
untouched.
But now for another GOTO story.
When I started my Stanford Pascal compiler adventure in 2011, the first
compiler pass (PASCAL1)
had around 50 GOTO statements in it (in fact: 50 numeric labels which are
targets of GOTOs in Pascal;
in Pascal, BTW, GOTOs are allowed, but they are sort of uncomfortable;
you need a label declaration for them, not only the GOTO statement and the
target label -
because the label is local to a block, the label number may be reused in
different blocks).
The Stanford compiler, as many other Pascal compilers, is self-hosted,
that means, it is written in Stanford Pascal and compiled by itself.
The Stanford Pascal compiler pass 1 had 6.000 lines in 2011 ... with the 50
labels mentioned above
(well, this was the 1982 McGill version, to be honest).
One of my first extensions to Stanford Pascal was to add CONTINUE, BREAK and
RETURN statements
to it (semantics like in C). It turned out that almost all GOTOs were used to
implement the missing
statements CONTINUE, BREAK and RETURN using GOTOs. I then started (after some
time)
to remove the GOTOs by replacing them by the new statements, where this was
possible
without problems.
Today the compiler pass 1 has almost 25.000 lines. It only contains 7 GOTO
statemens (I just checked it).
Because, see above, I am not dogmatic about GOTO, I will leave them, as long as
there is no need
to work on the procedures containing them.
The compiler story (including downloads) is here:
http://bernd-oppolzer.de/job9.htm
IMO, GOTOs (and the statements mentioned above) must be used with care.
If you don't use them right, nobody will be able to follow the logic in your
programs,
including yourself (after some time). Indentation is key, and meaningful
comments.
Kind regards
Bernd
Am 25.09.2022 um 13:51 schrieb David Crayford:
Another thing that makes me incredibly dubious about some of the opinions in these videos
is the hackneyed nonsense about "goto considered harmful". The original paper
was misunderstood in that all goto statements are harmful and brainwashed a generation.
Some of these videos present a trivial example using goto and refactor it using
if/ifelse. In programming languages without scope based cleanup goto is not harmful. In
fact it's leads to clean code as the branch direction is always descending to a cleanup
block. Happily for me, the young guys I work with writing systems level Metal/C code
haven't been seduced by this dogmatic BS. Good C code uses goto statements as opposed to
heavily nested or superfluously functionally decomposed routines. The IBM Openj9 JVM C
code is a case in point
https://github.com/eclipse-openj9/openj9/blob/master/runtime/vm/classsupport.c. I
challenge anybody to write better code without goto statements.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
