Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: Michael S <already5chosen@yahoo.com>
Newsgroups: comp.lang.c
Subject: Re: do { quit; } else { }
Date: Mon, 7 Apr 2025 21:02:48 +0300
Organization: A noiseless patient Spider
Lines: 131
Message-ID: <20250407210248.00006457@yahoo.com>
References: <vspbjh$8dvd$1@dont-email.me>
	<8634enhcui.fsf@linuxsc.com>
	<vsph6b$ce6m$5@dont-email.me>
	<86ldsdfocs.fsf@linuxsc.com>
	<20250406161323.00005809@yahoo.com>
	<86ecy5fjin.fsf@linuxsc.com>
	<20250406190321.000001dc@yahoo.com>
	<86plhodtsw.fsf@linuxsc.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Injection-Date: Mon, 07 Apr 2025 20:02:56 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="3a887cb259b636b775accca2c1064248";
	logging-data="404740"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+6Kui9LnyqVfVkz7xXkE9HHQsm2j2yWck="
Cancel-Lock: sha1:HzD81s+ZLFve8LaYeYaME2jQIWY=
X-Newsreader: Claws Mail 4.1.1 (GTK 3.24.34; x86_64-w64-mingw32)
Bytes: 7679

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.