Path: ...!weretis.net!feeder9.news.weretis.net!news.quux.org!eternal-september.org!feeder3.eternal-september.org!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: Thu, 24 Apr 2025 17:21:33 +0200
Organization: A noiseless patient Spider
Lines: 158
Message-ID: <vudktt$1q9ph$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>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Thu, 24 Apr 2025 17:21:34 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="c360d2cf90587f687238acb83b08ae4e";
	logging-data="1910577"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+d254OubGcq6FgqG7cT+rv94tU/N3pplA="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.11.0
Cancel-Lock: sha1:2YEoSoBDESBs989MO8HndF3ic2s=
Content-Language: en-GB
In-Reply-To: <vudhrb$1p05m$1@dont-email.me>
Bytes: 8150

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.

The C preprocessor directives are part of C, are described in the C 
standards, and are covered by all C tutorial books, courses, and similar 
material.  They take about 20 pages of the C standard of 700 pages (C11) 
- it is not hard to get the hang of typical use of macros in C.

They do not form a "language".  You get text-based macro substitution 
(without the possibility of recursion), conditional compilation, file 
inclusion, and error directives.  They are integral to C, and usually 
integral to C compilers.

Yes, there are some things that can be a bit fiddly - sometimes you need 
to have an extra layer of macro expansion for complicated things.  Most 
people don't need to do that sort of code, and if they do, you can 
figure it out with a bit of trial and error and some googling.

> 
> (But if someone is up to it, perhaps they can write 'make' in it!)
> 

The C preprocessor directives are not a programming language.

>>      + I can probably implement it in a few hundred lines of code
> 
> One Brainfuck interpreter I looked at (not sure if one of those at the 
> link below), involved 5000 lines of header code. But they can usually be 
> directly implemented in any normal language in about 50 lines.
> 

I can't figure out what you are trying to say here.  But it's probably 
not worth going into detail.

>>      + It will work with any C compiler, any target, and any C code
> 
> 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.

> 
>>      + It mixes freely with other C code
> 
> Not necessarily. Look at the 'datatype99' link here for example:
> 
>    https://github.com/hirrolot/awesome-c-preprocessor
> 
> That provides a new syntax for type definitions. While it can co-exist 
> with normal C code, it will be poorly matched.

These are macros for defining some types and macros for accessing those 
types with extra compile-time checks.  You can mix them freely with 
normal C code.  You don't have to use the macros for accessing the data 
- it's your choice.  And you can mix it all with other C code.

> 
> 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.

I also think writing identifiers and comments in Greek is incredibly 
confusing to someone who only reads English, but that does not mean 
Greek speakers should not be allowed to write code in Greek!

> 
>>      - Debugging it can be a bit of a pain
>>      - Complicated things can get a bit ugly with macro tricks
>>      - C macros are not Turing complete (no loops, recursion, etc.)
>>
>> Doing it "properly" means :
>>
>>      + The language can support anything I want it to
>>      - I have to design a whole language
>>      - I have to document a whole language
> 
> You will need docs anyway.

You need to document the use of the macros you write if you make macros 
- you need to document an entire language if you go that route.

> 
>>      - I have to implement a whole language and all the tools
>>      - It only works for the targets I bother supporting
>>      - No one else can use it without all the tools
>>      - It has to be a complete language on its own
>>      - Integration with other code is a PITA at best
> 
> That is going to be a problem anyway if you have this mysterious-looking 
> syntax in the middle of a C file.
> 

No, it is not.

>>      - The implementation in C probably uses lots of macros...
>>
>> The suggestion that making your own language and tools instead of a 
>> macro library is clearly absurd.
> 
> Who said devising a language was easy? But a CPP-based one will be poor. 

You suggested it would be a better idea than writing some C macros.

> Here's a comment from the Ferdi265/BF interpreter at that link:
> 
> "The preprocessor brainfuck interpreter is very very inefficient and 
> will use around 16 GIGABYTES of memory and 15 to 20 minutes of 
> processing time while running hello.bf."
> 

You do realise that Brainfuck is an intentionally silly language, made 
only for the fun and challenge of it?  And a C pre-processor 
implementation is also intentionally silly, for fun and the challenge?

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.

> If all you're thinking of is a library of functions and macros, then 
> fine, but that is not exactly a language.
> 
> 
>>> Or use a more appropriate base language.
>>
>> That is sometimes a much better option.
> 
> While not my thing, I was thinking of something like Racket.
> 
>