Re: do { quit; } else { }

On Mon, 07 Apr 2025 05:45:19 -0700
Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:

Michael S <already5chosen@yahoo.com> writes:
 

On Sun, 06 Apr 2025 07:32:16 -0700
Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
 

Michael S <already5chosen@yahoo.com> writes:
 

On Sun, 06 Apr 2025 05:47:47 -0700
Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
 

Furthermore, even if there had been a posting that concerns
only a gcc extension and nothing else, and is one I didn't
respond to, that doesn't excuse your action.  It isn't like
this is the first time you have posted something here that
is not about C but only about your fantasy language, and
also not the first time the unsuitability of such postings
has been pointed out.  You're a repeat offender.  So stop
pretending you are being picked on for no reason. 

>
Could you recommend a more appropriate place for Thiago and others
where they can discuss C-like fantasy languages? 

>
The newsgroup comp.lang.misc seems like a natural candidate.
I don't know if comp.lang.misc has an official charter, but at
least to me new features of any widely used programming language
would appear to fall under the umbrella of comp.lang.misc. 

>
My question was not completely abstract.
I did consider starting a discussion about possibility of inclusion
of stackless co-routines into one of the future editions of C.
Naturally, my ideas at this state are extremely in-concrete, much
more so then the post of Thiago Adams that started this thread.
So, if I ever come to it, which by itself is not very likely, do you
think that comp.lang.misc would be better place than comp.lang.c ? 

 
Before giving an answer I would like to ask some questions.
 
* How much does the (still fuzzy) idea depend on running in a C
  environment?  Is it very specific to C, or might it be applicable
  to other procedural/imperative languages (for example, Pascal)?
 
* How much does the current C language impact what you expect to
  propose?  Which aspects of C need to be taken into consideration
  in forming the proposal, and how strongly do those considerations
  affect the specifics of what would be proposed?
 

Of course, proposals for similar feature in other procedural/imperative
language would not be totally different. Pascal is more similar to C
than many other procedural languages, so solution for Pascal would
likely be more similar to C than for example, stackless co-routines
that already exist in such languages like C# (that started current wave
of popularity of the feature) or Python.
However Pascal and C have enough not in common for significant
difference in proposed syntax and implementation. Specifically, in
Pascal:
- heap management is built-n in the language
- non-local goto is built-n in the language
- nested procedures
- everything related to separated compilation of the translation units
is handwaved in the docs rather than strictly specified. May be it's
not so in Extended Pascal standard, I never read it.

Most importantly, Pascal in its hay days had different (from C)
attitude with regard to standardization. Implementors, especially
bigger ones, freely made very significant mutually incompatible
extensions and nobody in community was upset about it. C way is more
centralized.

* Assuming a proposed extension has been fully worked out, how
  broad or how narrow do you think the interest would be in the
  general C community for a future C standard to incorporate the
  proposed extension?
>

My own interest is for microcontrollers, primarily 32-bit
microcontrollers. Environments of interest are either without
multitasking library at all (my favorite) or with relatively simple
multitasking known as Real-time executives. In recent time the one
which is pushed by MCU vendors, which helps popularity rather immensely,
is called FreeRTOS.
These environments are characterized by not especially tight code
footprint but rather tight (writable) RAM footprint.

I don't believe that the feature is interesting for application
programming on "big" computers/OSes. IMHO, on "big" computers the same
objectives can be achieved in cleaner way through full (==stackfull)
coroutines or even by threads. Stackfull coroutines do not require
integration into programming language, esp. into relatively low-level
language, like C. They tend to be widely available for several decades
on majority of widely used OSes. And they tend to be ignored by C
programmers. Which, to me, suggests that the same would happen to more
limited stackless variant.
Anyway, application programming in C on "big" computers/OSes is a dying
field, and probably deservingly so.  WG14 Committee should acknowledge
the fact by putting their needs at lowest priority. Unlike that
programming MCUs in C is as healthy as ever. So should be prioritized
higher.

The 3rd field is kernel programming. I wrote my fare share of kernel
drivers for Windows and a couple for Linux, but it never was my passion.
Kernel programming always felt to me as unpleasant programming
experience. I know that other people feel very differently about it.
So, despite 1st hand experience, I don't consider myself qualified to
judge if stackless coroutines can fit here or not. Although my
unqualified opinion is "not".

* Assuming you get to a point where you are happy with the details
  of a proposed extension, how likely is it that you would write a
  proposal for the C standard committee, and make the effort needed
  to shepherd it through the process of being accepted for a future
  C standard?
 

Not likely. I would have to somehow convince somebody else to do it.

I realize you probably don't have firm answers for some or all of
these questions.  As part of figuring everything out, you might want
to start a discussion both of the general idea and also about what
the answers to these questions might be.  I think comp.lang.misc is
a good place to have such a discussion, even if your ideas are still
in the process of being formed;  the discussion could then serve the
dual purpose of getting the idea fleshed out and of determining how
strongly the idea should be considered as part of a future C
standard.