On 23/04/2025 19:43, bart wrote:
On 23/04/2025 16:31, David Brown wrote:
On 22/04/2025 22:03, bart wrote:
Too few levels of functions and/or macros (there is no semantic difference between macros and functions in this matter)
There is a great deal of difference. Functions tend to be well-formed in their inputs and outputs.
Macros take some abitrary blocks of syntax and return another arbitrary block of syntax:
#define INDEX(a, b, y) a y b
INDEX(a, i, [) ];
I know perfectly well that there are differences between what you can do with macros in C, and what you can do with functions.
In terms of dividing up code into manageable parts that fit together as a whole - and in doing so too much or too little - there is no conceptual difference between macros and functions.
I did ask at one point whether anybody could link to some truly terrible C code; nobody has so far.
>
There are probably two reasons for that. One is that everyone, except perhaps you, understands that this is very subjective. I've seen plenty of code posted in this group, written by regulars whose programming skill and knowledge I highly respect, and yet which I would classify as "truly terrible" and reject it immediately if it were presented to me for code review in my work. The other reason is that nobody else is particularly interested in seeing bad code, or going out of their way to look for it.
>
>
I just want to find out the threshold at which some will actually agree that macros have been abused or their use is over the top and unjustified.
>
>
Why?
>
We are all going to have different first-glance opinions on different bits of code.
What's your initial opinion of this 500-line example:
https://github.com/sal55/langs/blob/master/lisp.c
You missed the bit where I said I am not interested in examining bad code. Nor am I interested in Lisp, so I have no interest in looking at that.
Here's one of the functions from it:
lval rest(lval *h, lval *g) { lval *f = h-1; lval r = 0; for (; f>=g; f--)
r = cons(h, *f, r); return r; }
Presumably that makes sense to the people who wrote the code. But it makes no sense to me. That is /not/ because of some syntax or formatting issue, or the missing clause in the "for" loop - it is because I don't know the types, the functions (or macros) used, the purpose of this function, the way memory and resource management is handled in this code, the meaning of the single-letter identifiers, or anything else about it.
How the code is formatted is a drop in the ocean in the effort needed to understand the code, what it does, and where it fits with everything else in the code base.
Here's what my visualisation tool produces:
global function rest(ref i32 h, g)i64 =
ref i32 f
i32 r
f := h-1
r := 0
while f >= g do
r := cons(h,f^,r)
f--
od
return r
end
Yes, you might apply a C formatter too, and keep it in C, it won't fix that for-loop though.
The for-loop is basically irrelevant for understanding the code.
I fully agree that your "visualisation" here - or a re-factoring in C to use a "while" loop rather than a "for" loop - makes the code easier to read and makes it more obvious what the mechanics of the function are. And if I were writing the same function myself, I'd use a while loop rather than a for loop. So don't misunderstand me here - I am not a fan of the way that function is written. But I can't judge the format without a lot more context, and such judgement would be highly subjective. And the formatting is a very minor aspect of understanding the code.
But to form a solid, justifiable opinion I would want to see a lot more of the code in question.
Suppose this is a class of program which you have extensive experience of writing, but you see extra layers of complications that you'd never needed in yours, and the other program doesn't work any better either.
In fact it is poorer, and looks worse.
Would you still be as tolerant?
You want me to suppose that I know for sure that the code is more complex than it needs to be, and then you are asking me if I'll say it is more complex than it needs to be? Yes, under those circumstances I'd say it was more complex than it needs to be.
Would I be tolerant of it? That depends on why it is so complex, what the consequences of that complexity are, and the consequences of refactoring it to reduce the complexity. For single-use code that is unlikely to ever need to be changed or fixed, and which results in object code that is efficient enough for the task, it is not going to be worth the effort or risk to change. If the code is expected to be maintained over a long time period, re-used in other projects, or if many people need to understand it, then the balance could be very different.
Your questions here are like presenting someone with a picture and asking if it is good or not, without saying whether it was made by your six-year-old grandkid or hanging in an art gallery.
> but you're not considering how
> bizarre and crippling restriction it would be to put a cap on it.
>
There WILL be a cap.
>
No.
OK. I haven't been able to find a limit for nested, non-recursive macros. And I don't know how to set up a test for recursive macros (I'm not even sure they exist in C).
I'd expect most experienced C programmers to be able to answer that. I'd certainly expect anyone who claimed to have implemented a C preprocessor to be able to answer it. No, C does not have recursive macros (or any other kind of pre-processing loop), which is a significant limitation for some uses.
There are some limits for aspects of C given in the "translation limits" section of the standards, such as 4095 macro identifiers in a translation unit, which are minimum limits for conforming compilers. In practice, pretty much all C compilers have no caps or limits on these things other than the memory (or other limits) of the host computer.
If a language or tool supports recursion or loops during translation, then I agree a cap of some sort is a good idea. Alternatively there could be other detection of infinite loops, or a timeout. In C preprocessing, you can have recursion if a file includes itself (directly or indirectly), so a limit on file inclusion nesting makes sense. (For reference, gcc has 200 by default, but it is changeable by a command-line flag. The C standard requires a minimum of 15 levels.)
(I can do that my language, and that needs a cap since there are no conditional elements that would stop recursion. So this fails:
macro M = M + 1
But the same in C works, sort of, in that the second M here:
#define M M + 1
is not expanded.)
Very few things in this world are black-or-white.
>
Some deep nesting might be justified in special cases, for example some recursive macro that builds a string a character at a time.
>
But this was not such a case; it was simply decided to make it work using macros instead of functions.
>
How do you know that?
By the 500 such macro definitions, and the EXTENSIVE use of such macro invocations instead of functions, in a class of application I'm very familiar with.
So you don't know. You guessed.
You don't have any idea /why/ the developers choose to use macros like this - you simply assume that because you have written an interpreter with little use of macros, anyone else using macros for an interpreter (no matter how similar or different) must be doing something wrong.
(Again, I have no idea whether or not these macros are a good idea in the Lua source code - I am merely saying that your opinion here is highly subjective and is not based on any kind of objective rationale or full knowledge of the situation.)
>
>
As for being crippling: I've written all sorts of language apps, including interpreters like this, without ever using more than one level, and for several decades, zero levels.
>
>
And how do you know that is a good choice, or would be better in this case?
Near 40 years' experience of implementing interpreters? On some very resource-limited systems too. Ones that have always run rings around other products, until more recently when people are trying harder.
I know you have written interpreters for your own languages. I know you say they are fantastic and better than anything else in existence - since no one else has ever used them, we have only your word for that, but I'll assume it is true.
You /know/ I know that.
And yet I still asked you how you thought you were in a position to judge the way the Lua developers implemented Lua in such a categorical manner.
What your experience tells you is that is that it is /possible/ to implement a little virtual machine for a simple language without using C macros. It tells you nothing about whether or not it is a good idea, because you have not tried it out for comparison. It tells you nothing about how best to implement Lua in C, because that is a very different language from your languages. It tells you nothing about the best structure for a core project written by multiple people, with extensions written by hundreds or thousands of people, and with many orders of magnitude more end users - because you just have a one-person language.
And to cap it all, you (AFAIUI) don't even use C to implement any of this stuff - you use your own languages. (Those may well be a better choice than C for implementing virtual machines.)
The way you could /know/ the best way to implement a Lua virtual machine in C would be to investigate if the Lua developers, or any other groups, have tried to implement the Lua VM in different ways and seen how well they work. Or you could find books or articles that discuss different ways of implementing VMs.
There are perhaps a half-dozen basic ways of implementing language virtual machines. There are a very large number of interpreted or byte-coded languages. You have experience of implementing a couple of simple languages, for personal use, using either a strangely restricted subset of C or one of your own languages. Your experience tells you about your own experience - it tells you nothing about anyone else's experiences.
But those efforts are now centred on JIT-based products. This Lua product however is not JIT-based. (There is a separate LuaJIT project.)
(My latest interpreter does use macros. But there are only 25 across the project, which is for a bigger and richer language than Lua, and for an interpreter that runs faster. None of those are nested.
That product can be transpiled to C, and then it uses 0 C macros.)
A language like C provides all these odd-ball features, people are going to use them.
>
Macros are hardly odd-ball.
C ones are.
do { quit; } else { }
Re: do { quit; } else { }