From Newsgroup: comp.lang.c

Thiago Adams:

What do you think of this control block?
do
{
FILE f = fopen("file.txt", "r");

if (f == NULL) quit; /*goes to else part*/

/*success here*/
for (int i =0; i < 10; i++){
...
if (error) quit;
}

}
else
{
/*some error*/
}

I have come to the conclusion that lots of advanced and very
speficic control-flow structures are being invented to avoid
using `goto' -- a simple and generic solution, with the
additoinal bonus of keeping the semantically linear code
actually flat.

Your proposal is not bad: it is keeping the main code flat
and saves extracting the `do' part into a separate function
(to take advantage of `return`). The `else' keyword seems
misleading, because it is not strictly alternative to the
`do' part. Is it your purpose to re-use C's existing
keywords? If not, then consider `fail` instead of `quit`
and `onfail` instead of `else`. Also, `do' may be renamed
`failable', indicating a block with controlled failure.

P.S.: I am eternally unhappy with the control-flow mechanisms
in existing programming languages.
--
() ascii ribbon campaign -- against html e-mail
/\ www.asciiribbon.org -- against proprietary attachments
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 10/8/2025 8:14 AM, Anton Shepelev wrote:

Thiago Adams:

What do you think of this control block?
do
{
FILE f = fopen("file.txt", "r");

if (f == NULL) quit; /*goes to else part*/

/*success here*/
for (int i =0; i < 10; i++){
...
if (error) quit;
}

}
else
{
/*some error*/
}

I have come to the conclusion that lots of advanced and very
speficic control-flow structures are being invented to avoid
using `goto' -- a simple and generic solution, with the
additoinal bonus of keeping the semantically linear code
actually flat.

The problem with goto is define a name and to find this name
on the source code. Is it up or down?

"break" "continue" fixes the problem of defining a name and
restrict our search to "closest" iteration loop, we search
up.

"quit" here is similar of "break" and "continue".

Your proposal is not bad: it is keeping the main code flat
and saves extracting the `do' part into a separate function
(to take advantage of `return`). The `else' keyword seems
misleading, because it is not strictly alternative to the
`do' part. Is it your purpose to re-use C's existing
keywords? If not, then consider `fail` instead of `quit`
and `onfail` instead of `else`. Also, `do' may be renamed
`failable', indicating a block with controlled failure.

P.S.: I am eternally unhappy with the control-flow mechanisms
in existing programming languages.

I realized a problem with this keyword selection "do { }else {}".
The problem is that using "do" we don't what kind of "do" where are
until we find the "else" that is too late.

So, we need a different keyword to start the block.

Alternatives:

try {
throw; //error
quit; //early success - exit without going to catch
}
catch {
}



--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 08.10.2025 14:59, Thiago Adams wrote:

On 10/8/2025 8:14 AM, Anton Shepelev wrote:

I have come to the conclusion that lots of advanced and very
speficic control-flow structures are being invented to avoid
using `goto' -- a simple and generic solution, with the
additoinal bonus of keeping the semantically linear code
actually flat.

The problem with goto is define a name and to find this name
on the source code. Is it up or down?

The problems with 'goto' go even farther than only the technical
lookup; it goes into the semantical domain when jumping into and
out of scopes (for example).

Janis

[...]

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 08.10.2025 13:14, Anton Shepelev wrote:

[...]

P.S.: I am eternally unhappy with the control-flow mechanisms
in existing programming languages.

Can you elaborate, please?

Janis

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

Janis Papanagnou:

The problems with 'goto' go even farther than only the
technical lookup; it goes into the semantical domain when
jumping into and out of scopes (for example).

All true. I almost never use upwards-going goto (except for
loop-and-a-half), and I never jump inside scopes, only out
of them.
--
() ascii ribbon campaign -- against html e-mail
/\ www.asciiribbon.org -- against proprietary attachments
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 08.10.2025 16:08, Anton Shepelev wrote:

Janis Papanagnou:

The problems with 'goto' go even farther than only the
technical lookup; it goes into the semantical domain when
jumping into and out of scopes (for example).

All true. I almost never use upwards-going goto (except for loop-and-a-half), and I never jump inside scopes, only out
of them.

Some languages have restrictions and report such cases. But,
frankly, I cannot tell since I "abstain" from (mostly don't
even think to) using 'goto'. So when I actually want to use
'goto' I have to look up the language-specific rules anyway.
(Just recently, using an "old language", I ran into a funny
error where there was a conflict with the location of jump
labels and the location of declarations; I needed a kludge
to get it compiled.)

Janis

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 10/8/2025 9:59 AM, Thiago Adams wrote:
...

Alternatives:

try {
-a-a throw; //error
-a-a quit;-a //early success - exit without going to catch
}
catch {
}

quit also can be emulated with macros:


#define try if (1) {
#define catch quit_label:; } else catch_label:
#define throw goto catch_label
#define quit goto quit_label

int main(){

try
{
quit; /* success exit*/
//throw; /* catch */
}
catch
{
printf("catch\n");
}

printf("continuation...\n");
}


quit is useful for early success avoiding else { } else {}

try
{
if (case1)
{
ret = 1;
quit;
}

if (case2)
{
if (some_error)
throw;
ret = 2;
quit;
}

if (case3)
{
ret = 3;
quit;
}
}
catch
{
ret = -1;
}
return ret;

instead of

if (case1)
{
ret = 1;
}
else if (case2)
{
if (some_error)
{
ret = -1;
goto exit_label;
}
ret = 2;
}
else if (case3)
{
ret = 3;
}


exit_label:
return ret;



--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

No RAII ? Silly language !

Am 04.04.2025 um 21:23 schrieb Thiago Adams:

-a What do you think of this control block?

-a do
-a {
-a-a-a-a FILE f = fopen("file.txt", "r");

-a-a-a-a if (f == NULL) quit; /*goes to else part*/

-a-a-a-a /*success here*/
-a-a-a-a for (int i =0; i < 10; i++){
-a-a-a-a-a-a-a-a ...
-a-a-a-a-a-a-a-a if (error) quit;
-a-a-a-a }

-a }
-a else
-a {
-a-a-a-a /*some error*/
-a }

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

Em 15/10/2025 18:04, Bonita Montero escreveu:

No RAII ? Silly language !

I would be happy to chat about the disadvantages of RAII.
I think this is for another topic, and someone could complain that is
not about C. I think it is about C, why not introduce RAII in C.


--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 16/10/2025 00:41, Thiago Adams wrote:

Em 15/10/2025 18:04, Bonita Montero escreveu:

No RAII ? Silly language !

I would be happy to chat about the disadvantages of RAII.
I think this is for another topic, and someone could complain
that is not about C. I think it is about C, why not introduce
RAII in C.

Don't forget line numbers. And an environment division.
--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within
--- Synchronet 3.21a-Linux NewsLink 1.2