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

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.
I have not advocated for making any kind of "embedded language" in C, in any sense.

 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.

No, you did not - in either case.

 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.