Re: do { quit; } else { }

On 07/04/2025 19:02, Michael S wrote:

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

That's news to me. But then I only used an educational version.

- nested procedures
- everything related to separated compilation of the translation units
is handwaved in the docs rather than strictly specified.

I don't think it's that strictly specified in C. Isn't it vaguely left to the implementation?
Much of how different units share macros, types, structs and enums isn't part of the language at all AFAICS: it's just a by-product of different modules happening to include the same header files.
But it could also be done by repeating declarations in each module; it's rather ad hoc.
The Pascal I used only worked with one module; more recent versions do seem to have formal interfaces which are part of the language. So it is more rigorous than C.

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.

I have a feeling that there were WAY more variations of C than Pascal, largely because C was more popular and more widespread.
You still see this know when you delve into systems and applications headers which are often a mess of '#ifdef' blocks which special-case specific compiler versions which all have different characteristics.