Deutsch   English   Français   Italiano  
<vt15lq$bjs0$3@dont-email.me>

View for Bookmarking (what is this?)
Look up another Usenet article

Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: bart <bc@freeuk.com>
Newsgroups: comp.lang.c
Subject: Re: do { quit; } else { }
Date: Mon, 7 Apr 2025 19:31:23 +0100
Organization: A noiseless patient Spider
Lines: 100
Message-ID: <vt15lq$bjs0$3@dont-email.me>
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>
 <20250407210248.00006457@yahoo.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Mon, 07 Apr 2025 20:31:23 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="d1797a780321cb7d5295ec883a418a71";
	logging-data="380800"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+Y2jC57LJ8euSuZgZ6yevk"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:9D+zIQZHqvggK+Mwp9YEzm6R4mw=
In-Reply-To: <20250407210248.00006457@yahoo.com>
Content-Language: en-GB
Bytes: 5829

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.