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

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?
And can you honestly say that writing those complicated collections of macros requires no extra skill?
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.)

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. Now there is less variance, maybe because they're sharing the one implementation that got it just right.

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.
Remember I claimed such things to be 'impractical, unwieldy and inefficient' -'usually'.

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."
I gave an example of a tiny language needing 100 times as much source code to implement using C macros, as in a normal language, and another version of it that was hopelessy slow and inefficient.
And that's for a language which is normally as simple to implement, if not use, as they come.
So, do you have an actual example of an embedded language that is implemented more reasonably using macros?
By embedded 'language' I don't mean a library of function or macro definitions that you just call or invoked, as happens in any C program.