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

Liste des GroupesRevenir à cl c 
Sujet : Re: Loops (was Re: do { quit; } else { })
De : 643-408-1753 (at) *nospam* kylheku.com (Kaz Kylheku)
Groupes : comp.lang.c
Date : 21. Apr 2025, 21:25:58
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <20250421125957.29@kylheku.com>
References : 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27
User-Agent : slrn/pre1.0.4-9 (Linux)
On 2025-04-21, bart <bc@freeuk.com> wrote:
On 21/04/2025 19:43, Kaz Kylheku wrote:
On 2025-04-21, bart <bc@freeuk.com> wrote:
On 21/04/2025 04:16, Kaz Kylheku wrote:
- Because they are not gathered in one place, not only is it less>
readable, but we cannot use while write a macro such as:
>
       for_sqlite_hash (p, &pSchema->trigHash) {
         if (some_condition_over(p))
           continue; // doesn't stupidly repeat for the same p!
       }
>
I can't write such macros at all. I'm not even sure what this does.
 
Have you never worked with a large codebase written by someone other
than you?
>
How large are we talking about?

Several 100K to millions.

I've delved into largish apps in the context of getting my C compiler
working. I would describe that experience as 'brutal'.

Well, that brutal experience is the job of the career software engineer,
believe it or not. Very few work only on their own original code.

If you need to
debug someone else's codebase, not to find bugs in that program, but to
find why your implementation is failing, then you want as conservative a
coding style as possible.
>
>
When you open a random file in an unfamiliar code base, pretty
much any function call that is not in the standard library triggers
the "I don't know what this does" response.
>
Yes, a function call. Macros are in an entirely different, evil category.

No, they aren't. They are just another definition to understand.

They can be misused, and also used to make solutions that are more
complicated than some great ideas that don't involve macros.

So can anything: an open coded function can be misused to make some
complicated solution that can be more nicely done with macros.

The Lua sources (only a mere 30Kloc), use macros extensively, but also
have a habit of giving them ordinary looking names in lower case so that
they look like function calls.

So does ISO C; e.g. assert (expr); offsetof (type, member). So what?

Macros that provide syntax should blend into the language.

There is some sense in upper case for preprocessor constants.

Those that have short names can easily clash with variables.

Preprocessor constants are often under-typed.

Preprocessing such code doesn't help either, since a simple function
call can expand into a horrendously complex expression that can be 100s
of characters long and have parentheses nested 10 deep.
>
You have to learn some of that program's definitions in order to
effectively work with that program. At least those which are relevant to
your intended task.  You set up your "jump to definition" editor-fu and
start reading.
 
A loop macro like for_sqlite_hash (p, &pSchema->trigHash) is so obvious
>
Please humour me: What Does It Do?

It is intended to condense an interation that *you* open-coded, in this
example upthread:

       p = sqliteHashFirst(&pSchema->trigHash);
       while (p != NULL)
       {
           sqlite3DeleteTrigger(db, (Trigger*)sqliteHashData(p));
           p = sqliteHashNext(p) )
       }

So although I didn't show the definition, I think, of course the intent that it
does this (i.e. is relevant to the discussion thread) and not something else.

  for_sqlite_hash (p, hashptr) stmet

must initialize p using sqliteHashFirst(hashPtr); then
execute stmt if p is not not null, and step to the next entry
using sqliteHashNext(p), assigned back to p:

  #define for_sqlite_hash(P, H) \
   for ((P) = sqliteHashFirst(H); P; (P) = sqliteHashNext(P))

I'm taking it for granted that sqliteHashFirst, which came from your
post,  initiates an iteration, etc. I intuited that without needing it
explained.

that the only reason you'd look at its definition is to confirm that
it's not doing something stupid (which can be defined as just about
anything different from what it *looks* like it is doing).
 
I'd call that a win!
 
Now you're calling the inability of the programmer to implement a
nice space-saving notation over something verbose a "win".
 
If so, why isn't "for (a; b; c)" also a "win" over "do i = x, y".
>
Your example is just this:
>
      X(Y, Z)
>
and you're claiming it is something wonderful. Is it?

You're also claiming that "for X in A, B" (or what have you) is something
wonderful compared to "for (X = A; X <= B; X++)".

If I had to write 17 loops over SQLite hashes, I'd rather type
for_sqlite_hash(p, hash)  than
for (p = sqliteHashFirst(hash); p; p = sqliteHashNext(hash)).

I don't know. I
might guess from its name that it is something to do with loops.

You can guess from its name that it has something to do with loops
over sqlite hashes.

Just like I guessed from sqliteHashBegin that it has something to
with initiating an iteration over a hash, using a pointer-typed
cursor.

So what do X and Y represent, and what do they expand to?
>
What I might deduce, is that in C if you have a block of code like this:
>
    {body}
>
You can turn that into a loop by putting a for-header to its left:
>
    for(...) {body}
>
That for-header can come from a macro, so can be used to apply a loop to
such a block, without the code block itself needing to be a macro argument.
>
I will admit that is a useful side-effect of how a for-loop works, so
that it becomes a helpful feature if you ever need to write such macros.

I added a local variable binding extension to GNU Awk (in an Enhanced GNU Awk fork).

I gave it this syntax;

  let (x = 0, y = 1, z) { ... body ...}

guess why! This works with macros. This doesn't:

  { let x = 0, y = 1, z;  ... body ...}

I can't do that in my language; the macros are too simple, and the loop
body would need to be an argument, requiring closures etc. But then, the
existing loop features are adequate, and it is also easy to add new ones
by changing the language.

It's not easy to add new things by changing the language, when the language is
widely deployed, and implemented by multiple vendors.

Even the users who follow a single implementation might balk;
"Sorry, it has to work with the language that is packaged for Ubuntu 20".

It's a lot, lot better if a program can encode it sown language extension which
works with all major implementations going back 20 years in their versions.

A macro solution would anyway be poor in terms of nice syntax, error
reporting and so on.

Sure; but that can often be beaten by Works Everywhere.

(I'm just remembered I have a visualisation that can turn C syntax into
my syntax (but it's not good enough to compile). It turns:
>
>
     for(p=sqliteHashFirst(&pSchema->trigHash); p; p=sqliteHashNext(p)){
       sqlite3DeleteTrigger(db, (Trigger*)sqliteHashData(p));
     }
>
into:
>
     p := pSchema^.trigHash.first
     while p do
         sqlite3DeleteTrigger(db, ref Trigger(p^.data))
         p := p^.next
     od
>
You can now see that the C version involves macros. The increment has
now also been resolved into a simple member access.
>
Turning it into decent syntax and GETTING RID of macros has produced
cleaner looking code!)

In a clean room language, you have an opportunity to make an excellent
macro system which has answers for error reporting, identifier hygiene,
multiple evaluation ...

The weaknesses in C macros are a strawman against macros as such.

Yet, I will take C macros over no macros.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

Date Sujet#  Auteur
23 Apr 26 o 

Haut de la page

Les messages affichés proviennent d'usenet.

NewsPortal