Re: Loops (was Re: do { quit; } else { })

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.