Path: news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: David Brown <david.brown@hesbynett.no>
Newsgroups: comp.lang.c
Subject: Re: Loops (was Re: do { quit; } else { })
Date: Fri, 25 Apr 2025 15:19:12 +0200
Organization: A noiseless patient Spider
Lines: 189
Message-ID: <vug24g$gl4$1@dont-email.me>
References: <vspbjh$8dvd$1@dont-email.me> <vu01k7$1bfv2$1@dont-email.me>
 <vu0720$1dva7$1@dont-email.me> <vu2hmg$3jn88$1@dont-email.me>
 <vu2mkc$3noft$1@dont-email.me> <vu38da$735n$1@dont-email.me>
 <vu3j7s$g755$1@dont-email.me> <87ecxmv4t4.fsf@nosuchdomain.example.com>
 <vu401g$reom$1@dont-email.me> <20250420200823.908@kylheku.com>
 <vu5bqp$230jl$2@dont-email.me> <20250421113640.839@kylheku.com>
 <vu67up$2ubvr$1@dont-email.me> <20250421125957.29@kylheku.com>
 <vu6kkt$392e6$1@dont-email.me> <vu6q3b$3jhq1$1@paganini.bofh.team>
 <vu7r19$da0o$1@dont-email.me> <20250422103555.547@kylheku.com>
 <vu8sm8$18fhc$2@dont-email.me> <vub14h$3d9kt$1@dont-email.me>
 <vub8rh$3kfla$1@dont-email.me> <20250423113224.711@kylheku.com>
 <vubjnu$3tcis$1@dont-email.me> <vuddcj$1l3gf$1@dont-email.me>
 <vudhrb$1p05m$1@dont-email.me> <vudktt$1q9ph$1@dont-email.me>
 <vudsfk$22j1p$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 25 Apr 2025 15:19:13 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="0ae31ad591125cc8dc4c6b4a2207485c";
	logging-data="17060"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18Kos2j8/60sW48xEUYfMWC7hVmxSy7i5s="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.11.0
Cancel-Lock: sha1:3htaV1wvHcdSqhxFV2c1rR07prY=
In-Reply-To: <vudsfk$22j1p$1@dont-email.me>
Content-Language: en-GB

On 24/04/2025 19:30, bart wrote:
> On 24/04/2025 16:21, David Brown wrote:
>> On 24/04/2025 16:28, bart wrote:
>>> On 24/04/2025 14:12, David Brown wrote:
>>>> On 23/04/2025 22:49, bart wrote:
>>>
>>>>> Such libraries as I mentioned for embedded languages or syntax 
>>>>> wrapping are clever, but usually impractical, unwieldy and 
>>>>> inefficient.
>>>>
>>>> And as usual, I question your basis for making such wild general 
>>>> claims.
>>>>
>>>>>
>>>>> If you want a new language, do it properly! 
>>>>
>>>> Let's compare alternatives here.  If I want to make a little bit of 
>>>> embedded language, with C macros I have :
>>>>
>>>>      + The implementation is in a language I already know
>>>
>>> No. It is in the C preprocessor language. It is quite different from 
>>> C and requires special skills.
>>
>> Sometimes you talk a lot of bollocks.
> 
> Take a look at any ordinary C code of normal functions, statements etc.
> 
> Then look at the kind of impenetrable macros that are needed to do 
> ambitious things like emulate a new kind of syntax within a C file. That 
> will be a long list of #defines.
> 
> Can you honestly say that the person writing the former, and the one 
> writing the latter, are coding in the same language?

Perhaps we are talking at cross-purposes here.

The C preprocessor supports a few directives - such as #define.  It is 
not a language - it is part of standard C.  It is not hard to learn or 
understand, though there are a few awkward issues.  Of course it can be 
/used/ in ways that are hard to understand.

You seem to be talking about some imaginary "language" made by using 
extensive C macros and compiling with a C compiler.  I have never heard 
of such a thing, other than perhaps people doing things for fun or the 
challenge of it and the occasional person who wants to make C look more 
like Pascal by using "#define begin {" and "#define end }".

Sometimes people use a bit more advanced macros for simplifying their 
code or avoiding duplication of code.  That can be things like wrappers 
for easily defining tree-like structs with common "left" and "right" 
pointers, or for defining lists of rules with a common format, or using 
"x-macros" to let you generate a simple command-line interface where you 
can get the instruction parser, enumerations, help text, etc., generated 
from one list of commands instead of duplicating them.  All these things 
are examples of good use of complicated macro setups.  All of them can 
also be handled in alternative ways such as using other languages or 
external scripts for generating the C code, or simply duplicating the C 
code manually.

> 
> And can you honestly say that writing those complicated collections of 
> macros requires no extra skill?

Writing more complicated code always requires more skill than writing 
less complicated code.

> 
> If your answers are Yes then /you/ are the one talking bollocks.
> 
> (Maybe you've forgotten that Preprocessing is a C compilation stage 
> which performs a transformation from C with macro invocations, to pure C 
> with those invocations expanded.
> 
> To repeat, what I call a different language is the set of incantations 
> that form the body of each #define. They do not exist in the pure C 
> version.)

Please let me know if you are talking about writing macros as C 
programmers do regularly, or if you are talking about some very unusual 
usage of macro collections.  And if it is the later, please say if you 
are talking about developing such "macro libraries", or /using/ such macros.


> 
>>> Some will need a particular compiler or version because they rely on 
>>> some very specific behaviour.
>>
>> There is almost nothing compiler-specific about pre-processor 
>> directives.  I only know of two very minor extensions that gcc 
>> supports, for marginally nicer variadic macro support.  Of course the 
>> result of the macro expansion might be compiler-specific, just like 
>> any other C code you write without macros.
> 
> C compilers used to vary quite a bit in how macro expansions were done. 

Can you cite evidence of that?  Exclude any broken or non-standard 
compilers, or ones that only implement a bit of C, or ones written by 
people who haven't bothered reading the relevant parts of the C 
standards.  Also exclude any non-conformities around unrealistic 
situations (such as mixes of macro definitions across #include'd files).

> Now there is less variance, maybe because they're sharing the one 
> implementation that got it just right.

There are some C compilers that share front ends, but I expect that most 
will have their own pre-processors - either stand-alone, or, more often, 
integrated with the rest of the compiler.

> 
>>> It will also be incredibly confusing for someone looking at a source 
>>> file with a .c extension.
>>
>> I am not personally a fan of things like these macro packages - I'd 
>> rather just use C++.  But it's a matter of choice.  Even if you could 
>> argue that packages like "datatype99" are objectively bad in some 
>> sense (and you can't argue that), it would only be an argument against 
>> that use of macros, not C macros themselves or other use of them.
> 
> You're trying to avoid agreeing with me, that C files containing 
> constructs that emulate different syntax or different language elements, 
> are going to be confusing.

I happily agree that confusing code is confusing.  That applies to 
confusing functions, confusing types, confusing macros, confusing 
comments, and anything else, in any language, using any feature.  I 
don't agree that there is something special about macros in C that are 
confusing.

> 
> Remember I claimed such things to be 'impractical, unwieldy and 
> inefficient' -'usually'.

If you are talking about C macros, which you regularly complain about, 
then you are wrong.  (I say "wrong", rather than "I disagree with you", 
because macros are used so often by so many C programmers that it is 
obvious they are neither impractical, unwieldy, nor inefficient.)

If you are talking about some hypothetical extra embedded language 
written in macros, then it's a non-starter - such things are not used in 
real code, except in very niche cases when they are used precisely 
because they are the most convenient, efficient and safe method in those 
niche situations.

And if you are talking about something like that "datatype99" macro 
library, then your opinion is worthless unless you can show some 
real-world usage of it, compare it to real code in C doing a similar job 
without the macro library (or equivalent macros), and demonstrate that 
the "datatype99" version is clearly inferior.

You are, of course, welcome to your opinions - but if you can't justify 
them or show that they are reasoned opinions, they are worthless.

> 
>> If your best argument against C macros is that someone wrote a 
>> Brainfuck interpreter with them and it is inefficient, then I think 
>> you should retire from the discussion.
> 
> You seem to advocating using C macros to make an embedded language, 
> given that you say:
> 
> "The suggestion that making your own language and tools instead of a 
> macro library is clearly absurd."

Your imagination is running wild again.  Try reading what I wrote.

========== REMAINDER OF ARTICLE TRUNCATED ==========