From Newsgroup: comp.lang.c

On 25/04/2025 02:26, Keith Thompson wrote:

bart <bc@freeuk.com> writes:
[...]

I'm trying to stand up for myself as I'M AT THE END OF MY FUCKING
TETHER HERE.

ALL YOU PEOPLE WANT TO DO IS JUST TRASH EVERYTHING I'VE DONE.

EVERY SINGLE THING I SAY IS WRONG. NOTHING I SAY IS EVER
RIGHT. WHATEVER IT IS I SAY, YOU SAY THE OPPOSITE THING.

MY SELF-ESTEEM HAS NEVER BEEN LOWER - YOU HAVE DESTROYED ME.

[...]

Bart, if this is sincere, please consider stepping away from
comp.lang.c for a while. I have no motivation for this post other
than concern for your well-being.

Thank you, I'm fine.
--- Synchronet 3.21a-Linux NewsLink 1.2

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 {
   throw; //error
   quit;  //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:

  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*/
  }

--- 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