Sujet : Re: Loops (was Re: do { quit; } else { })
De : 643-408-1753 (at) *nospam* kylheku.com (Kaz Kylheku)
Groupes : comp.lang.cDate : 23. Apr 2025, 01:01:09
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <20250422164415.883@kylheku.com>
References : 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21
User-Agent : slrn/pre1.0.4-9 (Linux)
On 2025-04-22, bart <
bc@freeuk.com> wrote:
If you're going to criticize the macros, then hold the code constant.
If it is a given requirement that some code is to be written or
generated, and we have some macros which do that, are those macros a
"good" or "bad" solution?
>
Why use macros at all?
You need to repeat some verbose coding pattern without copy-and-paste
mistakes. If that coding pattern has a bug or has to be revised for any
reason, you want to do it in one place.
You need to control the evaluation of an argument expression, rather
than just receive its value.
You need to set up some code that declares variables or interacts
with declared identifiers in scope.
They might be a big deal in your own language, but in my experience,
largely in C, they seem to cause nothing but grief.
But:
for_sqlite_hash(p, hash) { ... }
has only one simple level of expansion; saves typing, no grief.
The fact that Lua has some grotty macros in its VM doesn't speak
to a nice use of macros, like what I was talking about.
You comitted a slippery slope type fallacy, or similar, by bringing
that up. "Macros /can/ be layered to 10 layers deeper and make the logic
inscrutable, therefore all macros are a bad idea, including a simple,
single-expansion iteration macro for sqlite hashes."
Here, it produces neither faster code nor smaller.
That's neither here nor there; all that matters is whether it's a good
way to produce the code that the author wanted.
Additionally, it may be possible to replace the implementation of the
macro such that it generates some other code that is faster, and such
that it remains compatible; all the calls to the macro remain valid, and
so new code for handling all the opcodes is generated.
The macro is called like this:
op_arith(L, l_addi, luai_numadd);
that's pretty abstract; chances are it could be preserved if
the implementation strategy were substantially altered.
-- TXR Programming Language: http://nongnu.org/txrCygnal: Cygwin Native Application Library: http://kylheku.com/cygnalMastodon: @Kazinator@mstdn.ca