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

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.
(But if someone is up to it, perhaps they can write 'make' in it!)

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

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

     + 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.
It will also be incredibly confusing for someone looking at a source file with a .c extension.

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

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

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