Bart wrote:

> One complex expression that my compiler had trouble with, when expanded,
> resulted in a line hundreds of character long, and using 11 levels of
> nested parentheses, the most I've ever come across.

Happen to remember particularly which that one was you?

--
Blue-Maned_Hawk│shortens to Hawk│/blu.mɛin.dʰak/
│he/him/his/himself/Mr.
blue-maned_hawk.srht.site
A resident complained about a neighbor blowing a duck horn. The police
informed him it was a crow.

Lawrence D'Oliveiro wrote:

> On Sun, 31 Dec 2023 22:57:12 -0800, Chris M. Thomasson wrote:
>
>> It was just an example of some fairly hard core macro magic.
>
> String-based macros aren’t “magic”, they’re just sad.

Preëmptive apologies for GitHub link, but: <https://github.com/Hirrolot/
datatype99>

See also (relevance partial only): <https://www.libcello.org/>

--
Blue-Maned_Hawk│shortens to Hawk│/blu.mɛin.dʰak/
│he/him/his/himself/Mr.
blue-maned_hawk.srht.site
There is nothing to catch in the magma pipe.

On 02/01/2024 10:42, David Brown wrote:
> On 01/01/2024 16:54, Bart wrote:

> I use macros for things like "Assert" and "Panic", where the controlling
> expression gets "stringified" and the function name, file and line
> numbers are included in the message that is printed and stored in logs.
> You can't do that without a preprocessor, unless the language supports a
> level of reflection well beyond the very limited forms found in D and
> C++ (and even the proposals for C++).
>
> I use macros for giving neater names to things that can't be made as
> functions, constants, etc., such as gcc __attributes__ or C++
> attributes, or lists of pragmas, especially in connection with
> conditional compilation to adapt to different compilers or platforms.
>
> I use macros if I need to replace something temporarily, such as for
> debugging or tracing part of a program.
>
> I use the preprocessor for generating unique names for things that need
> unique names for the language syntax, but for which I will never refer
> to by name.
>
> The most complex preprocessor stuff I have is probably use of so-called
> "x-macros".  I've used these to build simple command-line interfaces
> (with commands, sub-commands, and parameters, along with help text) and
> hierarchical menu systems.

X-macro are ugly. They are unreadable. At best, if someone has already
done the hard work of setting up a working set of macros, then you will
be able to see how to modify, add or delete entries.

For the purposes of creating parallel sets of enums and associated data,
I use special syntax which makes for a clearer and simpler feature.

Have you ever considered that if C didn't have macros, or they weren't
powerful, then it could have evolved superior, built-in alternatives?

>> One complex expression that my compiler had trouble with, when
>> expanded,   resulted in a line hundreds of character long, and using
>> 11 levels of nested parentheses, the most I've ever come across.
>>
>
> That's great - something that can help you find bugs or unnecessary
> limits in your compiler.

It wasn't a compiler limit - it was mine! The resulting expression was
completely unreadable. In the end I resorted to looking at the AST as
that was clearer than C source code.

> If you want to have something that works outside of scopes, being
> unscoped is an advantage.  It does not happen often, but it happens.
> Maybe you've got functions that needs a lot of calculations, using lines
> that follow a similar pattern.  Putting those patterns in a macro saves
> repetition in the source code, reduces the risk of errors, and makes the
> whole thing clearer.  But if the identifiers in the pattern have
> different scopes when they are used (perhaps they are in different
> functions), you can take advantage of macros' independence of scopes to
> avoid having to pass local data as parameters.

The scope I'm talking about is the name of the macro, not that of the
macro parameters.

>> They have normal scoping, so can be shadowed or have distinct versions
>> in different scopes and functions can define their own macros; they
>> can be imported or exported just like functions and variables.
>>
>
> So why not just use functions?

There are a few uses where functions won't work or would be inefficient.
My macros are easier to implement than inlined functions.

Half my use-cases involve inline assembly. Others involve creating
aliases for things like module names:

module mm_mcldecls as md

Now I can use md.F to disambiguate F instead of mm_mcldecls.F (when F is
exported by more than one module). Here the macro mechanism is used
internally.

The alternative here would be a special-purpose 'alias' feature but this
seems to work too.

>  Or implement more advanced core language
> features, like templates?
>
> The point of C preprocessor macros - the reason that they are useful in
> ways that cannot be handled by core language features - is that they are
> purely textual.  They exist outside of scoping, and language syntax.
> They can have unmatched brackets, or construct identifiers on the fly,
> or do all kinds of manipulation of code.  That allows for very powerful
> uses - and, of course, abuses.

Even when not being abused, their very use can cause problems, for
example when they appear in APIs for libraries that could be used across
an FFI.

Macros are a C language artefact, and what they expand to is arbitrary
C syntax that can be meaningless elsewhere.

(When I processed the GTK headers from 350,000 lines of C to 25,000
lines in my syntax, the last 4,000 lines were C macros that weren't
identifiable as simple named literals (eg #define A 100) and that would
need dealing with manually.)

> It is certainly the case that some common uses of macros in C have been
> made redundant by better language features in C++, D, and even in later
> versions of C.  Most common uses of #define'd constants are better
> handled by "static const" or "enum".  Most function-like macros are
> better handled by static inline functions, or C++/D templates.  Ugly
> C90/C99 style static_assert macros are best done with real
> _Static_assert from C11.  Many "tricks" that previously needed macros to
> get efficient code generation are made unnecessary by modern optimising
> compilers.
>
> So if you compare decades-old C code with modern C++, you should see a
> dramatic reduction in macros and pre-processor usage.
I haven't noticed. Things are bad enough now; are you saying they were
worse?

> You say "crude", others say "powerful" and "flexible".  The others would
> be right.

It's crude for many reasons, here's one:

#define x y

That is intended to replace instances of the top level name 'x' with
'y'. But in C, it also replaces 'x' in 'p.x' with 'p.y'.

In fact, any macro name you create is at risk of clashing with struct
member names. Such names are usually considered safe in a private
namespace; not in C!

>>
>> Some people will obviously love that, but imagine trying to search for
>> some token with a text editor, but it won't find it because it only
>> exists after preprocessing.
>>
>
> Imagine /not/ having macros, and having to type out those tokens again
> and again, when a macro could be defined once.  Then imagine wanting to
> change the tokens, and having to do so everywhere in the code instead of
> once in the definition.

I don't like macros, even the advanced ones in modern languages. I
consider them an anti-feature. And I did without them for decades, other
than for a time, simple ones with no parameters were used.

The parameterised ones I have now are an experiment. But every time I
use one, I get the same feeling as when I write 'goto'.

> It is not often that you get a free lunch - power and flexibility in one
> way will often limit things in other ways.  There are always tradeoffs,
> with all features, in all languages - I would have thought you might
> have learned that by now.

It's not a free lunch. A full CPP is quite difficult to implement,
possibly harder than C itself. The one I have is perhaps 90% there; it
will not do esoteric stuff.

On 02/01/2024 15:10, Blue-Maned_Hawk wrote:
> Bart wrote:
>
>> One complex expression that my compiler had trouble with, when expanded,
>> resulted in a line hundreds of character long, and using 11 levels of
>> nested parentheses, the most I've ever come across.
>
> Happen to remember particularly which that one was you?
>
>
>

No. You can have a look yourself if you like, just apply -E to the sources.

Here's one with quite a long expansion but not too deeply nested. This
is the line inside lvm.c at line 1463:

op_arith(L, l_addi, luai_numadd);

The expansion is:

{TValue*v1=(&((base+((((int)((((i)>>((((0+7)+8)+1)))&((~((~
(Instruction)0)<<(8)))<<(0)))))))))->val);TValue*v2=(&((base+((((int)
((((i)>>(((((0+7)+8)+1)+8)))&((~((~(Instruction)0)<<(8)))
<<(0)))))))))->val);{StkId ra=(base+(((int)((((i)>>((0+7)))&((~((~
(Instruction)0)<<(8)))<<(0)))))));if(((((v1))->tt_)==(((3)|((0)<<4))))&&
((((v2))->tt_)==(((3)|((0)<<4))))){lua_Integer i1=(((v1)->value_).i);
lua_Integer i2=(((v2)->value_).i);pc++;{TValue*io=((&(ra)->val));
((io)->value_).i=(((lua_Integer)(((lua_Unsigned)(i1))+((lua_Unsigned)(i2)))));
((io)->tt_=(((3)|((0)<<4))));};}else{lua_Number n1;lua_Number
n2;if((((((v1))->tt_)==(((3)|((1)<<4))))?((n1)=(((v1)->value_).n),1):
(((((v1))->tt_)==(((3)|((0)<<4))))?((n1)=((lua_Number)
(((((v1)->value_).i)))),1):0))&&(((((v2))->tt_)==(((3)|((1)<<4))))?
((n2)=(((v2)->value_).n),1):(((((v2))->tt_)==(((3)|((0)<<4))))?((n2)=
((lua_Number)(((((v2)->value_).i)))),1):0))){pc++;{TValue*io=
((&(ra)->val));((io)->value_).n=(((n1)+(n2)));((io)->tt_=(((3)|
((1)<<4))));};}};};};

This is the definition of that macro:

#define op_arith(L,iop,fop) { \
TValue *v1 = vRB(i); \
TValue *v2 = vRC(i); \
op_arith_aux(L, v1, v2, iop, fop); }

were 'op_arith_aux' is another macro. Actually, probably everything is.

This looks fun to try to understand, debug, or port.

Here you might well ask why inlined functions weren't better suited.

On 02/01/2024 17:12, Bart wrote:
> On 02/01/2024 10:42, David Brown wrote:
>> On 01/01/2024 16:54, Bart wrote:
>
>
>> I use macros for things like "Assert" and "Panic", where the
>> controlling expression gets "stringified" and the function name, file
>> and line numbers are included in the message that is printed and
>> stored in logs. You can't do that without a preprocessor, unless the
>> language supports a level of reflection well beyond the very limited
>> forms found in D and C++ (and even the proposals for C++).
>>
>> I use macros for giving neater names to things that can't be made as
>> functions, constants, etc., such as gcc __attributes__ or C++
>> attributes, or lists of pragmas, especially in connection with
>> conditional compilation to adapt to different compilers or platforms.
>>
>> I use macros if I need to replace something temporarily, such as for
>> debugging or tracing part of a program.
>>
>> I use the preprocessor for generating unique names for things that
>> need unique names for the language syntax, but for which I will never
>> refer to by name.
>>
>> The most complex preprocessor stuff I have is probably use of
>> so-called "x-macros".  I've used these to build simple command-line
>> interfaces (with commands, sub-commands, and parameters, along with
>> help text) and hierarchical menu systems.
>
> X-macro are ugly. They are unreadable.

Speaking as someone who has used them in real code, rather than someone
with a pathological hatred of macros and who prefers knee-jerk reaction
to their uses instead of applying a few minutes objective thought,
"x-macros" can make code significantly simpler, clearer, and much easier
to maintain correctly.

> At best, if someone has already
> done the hard work of setting up a working set of macros, then you will
> be able to see how to modify, add or delete entries.

They are not hard. Perhaps you don't actually understand what is
usually meant by "x-macros" ?

>
> For the purposes of creating parallel sets of enums and associated data,
> I use special syntax which makes for a clearer and simpler feature.

And that is, obviously, utterly useless - because it is not C or even a
commonly supported extension. Oh, and even if it /were/ part of C, it
would not help because that's not what I was doing.

>
> Have you ever considered that if C didn't have macros, or they weren't
> powerful, then it could have evolved superior, built-in alternatives?
>

The C preprocessor is part of C - it is already built in.

But I have already mentioned, several times, how other language features
of C and C++ are better choices than macros for the uses that they
cover. Or does your desperate need to rant against C and macros blind
you to reading other people's posts? (I'd appreciate an answer here -
it will let me know if there is any point in trying to educate you or
answer your questions.)

>
>>> One complex expression that my compiler had trouble with, when
>>> expanded,   resulted in a line hundreds of character long, and using
>>> 11 levels of nested parentheses, the most I've ever come across.
>>>
>>
>> That's great - something that can help you find bugs or unnecessary
>> limits in your compiler.
>
> It wasn't a compiler limit - it was mine! The resulting expression was
> completely unreadable.

I wonder if the code authors also found this expanded expression
unreadable. I guess not - because they used macros so that they could
write it in a clear and understandable way, and never have to look at
the expansion! You don't seem to comprehend the point of macros at all.

> In the end I resorted to looking at the AST as
> that was clearer than C source code.
>

Why not just look at the code as written, if you want to understand it?
Or would doing something that sensible put a damper on your rants?

>> If you want to have something that works outside of scopes, being
>> unscoped is an advantage.  It does not happen often, but it happens.
>> Maybe you've got functions that needs a lot of calculations, using
>> lines that follow a similar pattern.  Putting those patterns in a
>> macro saves repetition in the source code, reduces the risk of errors,
>> and makes the whole thing clearer.  But if the identifiers in the
>> pattern have different scopes when they are used (perhaps they are in
>> different functions), you can take advantage of macros' independence
>> of scopes to avoid having to pass local data as parameters.
>
> The scope I'm talking about is the name of the macro, not that of the
> macro parameters.
>

I was talking about the scope of parameters and any identifiers in the
macro definition.

For the name of the macro itself, I can agree that I don't see any
advantage in it being scope-free. I can't think off-hand of a situation
where it would be particularly useful to define a macro inside a block
scope in a function and have it work outside that scope too. (It's
obvious why macro names cannot be scoped.)

>
>>> They have normal scoping, so can be shadowed or have distinct
>>> versions in different scopes and functions can define their own
>>> macros; they can be imported or exported just like functions and
>>> variables.
>>>
>>
>> So why not just use functions?
>
> There are a few uses where functions won't work or would be inefficient.

If functions are inefficient, that is a weakness in your compilation.
Don't you do any kind of inlining or inter-procedural optimisations? I
realise these are not easy to implement, but the potential gains are
significant.

> My macros are easier to implement than inlined functions.
>

So they are like a limited form of inline functions? Okay, that might
be useful to get better code from a weaker compiler, but that's hardly a
benefit compared to real macros.

> Half my use-cases involve inline assembly.

Why can't that be in inlined functions? Again, you are not showing that
these limited macros have any benefits compared to what is found in C,
you are merely saying you have something that partially counters the
limitations of your tools.

(And to be clear - I fully appreciate that making advanced compiler
optimisations is very difficult, and this is a good solution for you
when making everything yourself. But it is not a positive feature or
selling point for your language - it is a workaround for practical
limitations.)

> Others involve creating
> aliases for things like module names:
>
>     module mm_mcldecls as md
>
> Now I can use md.F to disambiguate F instead of mm_mcldecls.F (when F is
> exported by more than one module). Here the macro mechanism is used
> internally.

Aliases in module imports are common (and useful) in many languages.
They are not "macros" in any sense.

>
> The alternative here would be a special-purpose 'alias' feature but this
> seems to work too.
>

It is completely irrelevant how this is all implemented internally. It
doesn't matter if it is done using the same bit of code that handles
your limited macros, or if it is something else entirely. It only
matters how it works to the language user - and it's a module alias, not
a macro.

>>   Or implement more advanced core language features, like templates?
>>
>> The point of C preprocessor macros - the reason that they are useful
>> in ways that cannot be handled by core language features - is that
>> they are purely textual.  They exist outside of scoping, and language
>> syntax. They can have unmatched brackets, or construct identifiers on
>> the fly, or do all kinds of manipulation of code.  That allows for
>> very powerful uses - and, of course, abuses.
>
> Even when not being abused, their very use can cause problems, for
> example when they appear in APIs for libraries that could be used across
> an FFI.
>

C code is written for use in C. Limitations or quirks of other
languages that try to interface to that code are not the responsibility
of the C language.

People writing code in one language with the intention of having it
reusable in other languages have a responsibility to try to make this
simpler. (Just as people writing reusable library code have a
responsibility to document the code more than they might for a
self-contained project.)

> Macros are a C language artefact, and what they expand to is arbitrary C
> syntax that can be meaningless elsewhere.

Yes - C code is C code. It is not Pascal, or Fortran, or Ada. Should
this be a surprise?

On 2023-12-31, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
> On Sun, 31 Dec 2023 16:25:08 +0100, David Brown wrote:
>
>> I realise that you (and possibly others) might find it useful for a tool
>> to replace typedef identifiers with their definitions, but it could only
>> be done for some cases, and is not as simple as macro substitution.
>
> String-based macros are nothing but trouble. Typedefs are scoped, string
> macros are not.
>
> If you want to see the right way to do macros, look at LISP, where they
> are token-based, and much more robust as as result. I think they even
> manage to apply scoping rules to macro definitions as well.

By the way, I'm not sure what system you are referring to by
"string-based macros", but in case you might be thinking of C
preprocessing, be advised that it's token-based.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.

On Tue, 2 Jan 2024 12:24:45 +0000, Bart wrote:

> You're going to defend this to the death aren't you? Be funny if at some
> point some GMP II was produced whose main new benefit was a vastly
> simplified build!

Well, you can go back to dreaming if you wish. It’s not like this project
was just created yesterday: if it was going to pay more serious attention
to Microsoft Windows, it would have done so already. Clearly the need
isn’t there.

> By doing searches, I found a bunch of libxxx.a files with today's date
> in various locations.

I would say you forgot to do the “make install” bit. That would put the
build products in some sensible place, like /usr/local.

> So the outputs are archive files for gcc, I guess intended for static
> linking.

As I mentioned, the build script has options for both static and dynamic
builds. Maybe you chose the wrong one. Tip: try “./configure --help” for a
quick summary of the build options.

> The INSTALL file talks about reading detailed instructions in gmp_info,
> but this file is gobbledygook. You need to view the instructions using a
> program called 'info' - a Linux utility that doesn't exist on Windows.

Again, that’s the fault of Windows for being such a poverty-stricken OS.

Remember, Windows is designed as a platform on which users will not do
their own programming, but instead they will buy programs from software
vendor organizations. All the tooling is centred around that, and is built
on the assumption that Microsoft will provide the core development tools.

> So I need Linux even just to look at a bunch of instructions?

You need Linux to do any kind of serious open-source or cross-platform
development work, yes.

> What, God forbid, if 'gcc -E' was not supported?

What, indeed. I _did_ mention, did I not, that this project has a lot of
support for obsolete, proprietary Unix systems with their own peculiar
quirks. Certainly enough users must still care about those for this
support for them to be retained in the project. Yet there are not enough
of these complaining Windows users (or should I say “sufferers”) for them
to be catered to.

> And why aren't these checks everytime you build /any/ program?

Different projects have different requirements. GNU autoconf has a whole
standard library of things to check for (and configure your build for),
and you can add new ones by writing suitable m4 definitions.

Here, you can read about it yourself:
<https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.71/
autoconf.html>.

> What a total waste of time.

A good description of Microsoft Windows generally. That’s why those of us
who want to be productive tend to avoid it.

> GMP, when it's actually made available, is actually an incredibly fast
> library. Some talented people went into creating it. I can't say the
> same for those responsible for the build system who seem to have made it
> as complicated and convoluted as they possibly can.

You yourself said, it only took 5 minutes to build--on Linux.

As the Dilbert cartoon goes: “Here’s a nickel, kid. Get yourself a *real*
computer.”

On Tue, 2 Jan 2024 18:16:36 -0000 (UTC), Kaz Kylheku wrote:

> By the way, I'm not sure what system you are referring to by
> "string-based macros", but in case you might be thinking of C
> preprocessing, be advised that it's token-based.

Now go learn what “homoiconicity” means.

On 02.01.2024 17:38, Bart wrote:
> On 02/01/2024 15:10, Blue-Maned_Hawk wrote:
>> Bart wrote:
>>
>>> One complex expression that my compiler had trouble with, when expanded,
>>> resulted in a line hundreds of character long, and using 11 levels of
>>> nested parentheses, the most I've ever come across.
>>
>> Happen to remember particularly which that one was you?
>>
>>
>>
>
> No. You can have a look yourself if you like, just apply -E to the sources.
>
> Here's one with quite a long expansion but not too deeply nested. This
> is the line inside lvm.c at line 1463:
>
> op_arith(L, l_addi, luai_numadd);
>
> The expansion is:
>
> {TValue*v1=(&((base+((((int)((((i)>>((((0+7)+8)+1)))&((~((~
> (Instruction)0)<<(8)))<<(0)))))))))->val);TValue*v2=(&((base+((((int)
> ((((i)>>(((((0+7)+8)+1)+8)))&((~((~(Instruction)0)<<(8)))
> <<(0)))))))))->val);{StkId ra=(base+(((int)((((i)>>((0+7)))&((~((~
> (Instruction)0)<<(8)))<<(0)))))));if(((((v1))->tt_)==(((3)|((0)<<4))))&&
> ((((v2))->tt_)==(((3)|((0)<<4))))){lua_Integer i1=(((v1)->value_).i);
> lua_Integer i2=(((v2)->value_).i);pc++;{TValue*io=((&(ra)->val));
> ((io)->value_).i=(((lua_Integer)(((lua_Unsigned)(i1))+((lua_Unsigned)(i2)))));
>
> ((io)->tt_=(((3)|((0)<<4))));};}else{lua_Number n1;lua_Number
> n2;if((((((v1))->tt_)==(((3)|((1)<<4))))?((n1)=(((v1)->value_).n),1):
> (((((v1))->tt_)==(((3)|((0)<<4))))?((n1)=((lua_Number)
> (((((v1)->value_).i)))),1):0))&&(((((v2))->tt_)==(((3)|((1)<<4))))?
> ((n2)=(((v2)->value_).n),1):(((((v2))->tt_)==(((3)|((0)<<4))))?((n2)=
> ((lua_Number)(((((v2)->value_).i)))),1):0))){pc++;{TValue*io=
> ((&(ra)->val));((io)->value_).n=(((n1)+(n2)));((io)->tt_=(((3)|
> ((1)<<4))));};}};};};
>
> This is the definition of that macro:
>
> #define op_arith(L,iop,fop) { \
> TValue *v1 = vRB(i); \
> TValue *v2 = vRC(i); \
> op_arith_aux(L, v1, v2, iop, fop); }
>
> were 'op_arith_aux' is another macro. Actually, probably everything is.
>
> This looks fun to try to understand, debug, or port.
>
> Here you might well ask why inlined functions weren't better suited.

Cpp macros, inline functions, etc. - it's somehow funny, but probably
explainable because we're in a NG topical to the C language.

During the 1980's (when I learned quite some different language types)
we were taught that [these sorts of] optimizations are (or should be)
the task of the compilers not of the programmers; programmers should
(WRT optimizations) focus on the algorithmic complexity.

Here in CLC I'll probably get lapidated for (still) considering C as a
perfect [almost] machine independent assembler language (sort of). :-)

In our role as C programmers we have to live with what we've got, and
tools (or later language extensions) help us...

That said; during my early K&R C era we had 'register' declarations,
but I rarely saw them, they seem to have quickly vanished from usage.
Now I've heard that 'inline' optimizations have been introduced in C.
Isn't that considered a task for the compiler? (I mean there's already
the -O option levels available. But, OTOH, I occasionally hear about
problems with some -O levels...)

Janis

On Tue, 2 Jan 2024 20:23:24 +0100, Janis Papanagnou wrote:

> That said; during my early K&R C era we had 'register' declarations, but
> I rarely saw them, they seem to have quickly vanished from usage. Now
> I've heard that 'inline' optimizations have been introduced in C. Isn't
> that considered a task for the compiler?

Kids’ stuff. Want to see how a _real_ compiler does it?
<https://gcc.gnu.org/onlinedocs/gcc-13.2.0/gcc/Attribute-Syntax.html>

On 02.01.2024 20:35, Lawrence D'Oliveiro wrote:
> On Tue, 2 Jan 2024 20:23:24 +0100, Janis Papanagnou wrote:
>
>> That said; during my early K&R C era we had 'register' declarations, but
>> I rarely saw them, they seem to have quickly vanished from usage. Now
>> I've heard that 'inline' optimizations have been introduced in C. Isn't
>> that considered a task for the compiler?
>
> Kids’ stuff. Want to see how a _real_ compiler does it?
> <https://gcc.gnu.org/onlinedocs/gcc-13.2.0/gcc/Attribute-Syntax.html>

What shall I infer from that statement and link? - Mind to elaborate?

My original question was related to compiler (as opposed to programmer)
doing optimizations. I recall from decades ago that compilers will do
optimizations e.g. on the attributed syntax tree level, while 'register'
or 'inline' seem very primitive constructs (on a comparable low level).
So I expressed my astonishment that 'inline' had been later introduced
in C, and I wonder why. (Note that the other poster also mentioned it
as a preferred way to replace [parameterized] macros, if I interpreted
him correctly.)

Janis

Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>On Mon, 1 Jan 2024 11:56:00 +0000, Bart wrote:
>
>> On 01/01/2024 02:00, Lawrence D'Oliveiro wrote:
>>
>>> Those are just standard file-manipulation tools that any decent OS
>>> should provide.
>>
>> What's that got to do with building able to build programs easily?
>
>You have effectively answered that question yourself. Why were you trying
>to build GNU GMP on Windows? Isn’t there something equally capable and yet
>more, shall we say, “native” to Windows, that you can build and use in a
>more “Windows-native” fashion?

And the 'G' in GMP stands for GNU. Expecting FSF to do anything
to support windows is insane.

Bart <bc@freeuk.cm> writes:
>On 02/01/2024 06:47, Lawrence D'Oliveiro wrote:
>> On Tue, 2 Jan 2024 06:23:03 -0000 (UTC), Kaz Kylheku wrote:
>>
>>> On 2024-01-02, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>>>
>>>> First of all, it includes code for building on a whole lot of
>>>> proprietary Unix systems with non-GCC compilers, some of which maybe
>>>> don’t quite conform to official C/C++ standards.
>>>
>>> When people use Autoconf to configure their program for building, the
>>> generated script includes cruft for platforms on which they never tested
>>> the program, and never will, and on which it won't work for reasons not
>>> related to those tests.
>>
>> This is a GNU project, so you can be sure they have done pretty good
>> testing on those platforms and those options. If they were no longer
>> supported, they would have been dropped from the code. This isn’t like
>> proprietary software, which tends to accumulate cruft that nobody dares
>> touch because they no longer understand what it does.
>>
>>>> Look at the ABI options: maybe you want a 32-bit build (where the CPU
>>>> supports it) rather than a 64-bit one; on some architectures, things
>>>> get a bit more complicated than just those two options.
>>>
>>> These kinds of options can be passed in by CFLAGS, LDFLAGS and LDLIBS.
>>> Support those three variables, and that's it.
>>
>> If you have a look, that’s what the script does. Only you just have to
>> specify one option, and it generates the right value for *all* the
>> relevant variables, instead of you having to specify them individually.
>
>
>You're going to defend this to the death aren't you? Be funny if at some
>point some GMP II was produced whose main new benefit was a vastly
>simplified build!

You still haven't provided a better system that accomplishes
everthing the existing system does.

Quit bitching about it and _do_ something about it. It's an open
source system, you are free to contribute a new build system for
it (which clearly needs to support all the capabilities of the
existing system otherwise you'll never have your suggestions
accepted).

Don't, however, expect anyone to cater to you.

>
>I tried to build gmp today using WSL. The process took just under five
>minutes. However, where and what is the output? For all the verbosity,
>that simple fact is omitted.

You presumably specified that on the ./configure with the --prefix
option. Or did you forget to RTFM first?

On 02/01/2024 17:34, David Brown wrote:
> On 02/01/2024 17:12, Bart wrote:

>> X-macro are ugly. They are unreadable.
>
> Speaking as someone who has used them in real code, rather than someone
> with a pathological hatred of macros and who prefers knee-jerk reaction
> to their uses instead of applying a few minutes objective thought,
> "x-macros" can make code significantly simpler, clearer, and much easier
> to maintain correctly.

I'm sorry, but I *DO* find them utterly impossible. This is a simple
example from Stackoverflow of someone wanting to define a set of enums
with an accompanying table, whose problem was in ensuring the two were
kept in sync.

The X-macro solution was this, adapted from the first answer here
(https://stackoverflow.com/questions/6635851/real-world-use-of-x-macros);
assume those functions are in scope:

-------

#define STATE_TABLE \
ENTRY(STATE0, func0) \
ENTRY(STATE1, func1) \
ENTRY(STATE2, func2) \
ENTRY(STATE3, func3) \

enum
{ #define ENTRY(a,b) a,
STATE_TABLE
#undef ENTRY
NUM_STATES
};

void* jumptable[NUM_STATES] =
{ #define ENTRY(a,b) b,
STATE_TABLE
#undef ENTRY
};
-------

With my feature, it is merely this:

global enumdata []ref void jumptable =
(state1, func1), # comment 1
(state2, func2),
(state3, func3), # comment 3
(state4, func4),
end

Notice:

(1) I don't need any of those weird macros.

(2) I don't need those backslashes

(3) I can add comments to any entry in the table.

(4) The 'global' attribute means both enumeration names and the array
are exported to other modules. Doing the same in C is tricky.

But I'm wasting my time because you are never going to admit my feature
is superior to X-macros for this purpose.

(The author of this example goes on to say how it can also be used to
define a set of function prototypes. I can't do that with my feature.
But then I don't need function prototypes!)

>> At best, if someone has already done the hard work of setting up a
>> working set of macros, then you will be able to see how to modify, add
>> or delete entries.
>
> They are not hard.

Maybe not for you, but it would take me ages to come up with the right
incantations to make it work.

>> For the purposes of creating parallel sets of enums and associated
>> data, I use special syntax which makes for a clearer and simpler feature.
>
> And that is, obviously, utterly useless - because it is not C or even a
> commonly supported extension.  Oh, and even if it /were/ part of C, it
> would not help because that's not what I was doing.

I've given an example of a use-case for C macros which have a special
purpose feature in other languages. So of cause it's not in C.

>>
>> Have you ever considered that if C didn't have macros, or they weren't
>> powerful, then it could have evolved superior, built-in alternatives?
>>
>
> The C preprocessor is part of C - it is already built in.

You missed my point. Take a tiny feature like being able to easily get
the size of a fixed-length array. You commonly see macro like this:

#define LENGTH(a) (sizeof(a)/size(a[0]))

What incentive is there to properly add a built-in way to do that, when
it can be done, badly, and in 1000 different ways by each user, in a
one-line macro?

Another example is GETBIT(a, n).

>> It wasn't a compiler limit - it was mine! The resulting expression was
>> completely unreadable.
>
> I wonder if the code authors also found this expanded expression
> unreadable.

Look at the example I posted in reply to Blue-Maned_Hawk.

In particular consider my last comment.

> I guess not - because they used macros so that they could
> write it in a clear and understandable way, and never have to look at
> the expansion!  You don't seem to comprehend the point of macros at all.
>
>> In the end I resorted to looking at the AST as that was clearer than C
>> source code.
>>
>
> Why not just look at the code as written, if you want to understand it?

In my case I was debugging my C compiler. Then you need to examine the
actual expanded code in detail. Excessive use of macros makes that much
harder.

That example came from Lua 5.4, an interpeter whose performance on a par
with my own product running from HLL-only code. That doesn't doesn't use
deeply-nested macro like this, and it doesn't appear to suffer,.

> Or would doing something that sensible put a damper on your rants?

Look, I'm written a C preprocessor (I suspect you haven't). If I wanted,
I could adapt it to work on my own languages.

But I /don't/ want to. Obviously I see something undesirable about them
(I don't like metaprogramming in general; people get too carried away
with it and want to show off their skills).

Why can't you accept that?

>> Half my use-cases involve inline assembly.
>
> Why can't that be in inlined functions?

That doesn't work in inline assembly.

> Again, you are not showing that
> these limited macros have any benefits compared to what is found in C,

That's true. I can't write something like:

#define M a+b)*c

(M;

>> Macros are a C language artefact, and what they expand to is arbitrary
>> C syntax that can be meaningless elsewhere.
>
> Yes - C code is C code.  It is not Pascal, or Fortran, or Ada.  Should
> this be a surprise?

It's inconvenient. This is a macro from SDL2:

#define SDL_CompilerBarrier() \
{ SDL_SpinLock _tmp = 0; SDL_AtomicLock(&_tmp);
SDL_AtomicUnlock(&_tmp); }

Rather than declaring a function which resides in a language-neutral
DLL, it declares it here, in the form of actual C code.

Even given a language with an FFI that is capable of calling external
functions compiled as C, what are they supposed to do with this?

That example was in a conditional block; I don't know the context. But
here's a juicy one that is the result of an attempt to automatically
translate the C SDL2 API to my syntax:

global macro SDL_FOURCC(A,B,C,D) =
((SDL_static_cast(Uint32,SDL_static_cast(Uint8,(A)))<<0)|(SDL_static_cast(Uint32,SDL_static_cast(Uint8,(B)))<<8)|(SDL_static_cast(Uint32,SDL_static_cast(Uint8,(C)))<<16)|(SDL_static_cast(Uint32,SDL_static_cast(Uint8,(D)))<<24))

This also contains arbitrary C code; it needs a much more sophisticated
tool than one that just does declaration. Basically a transpiler from
C to the language one is writing bindinds for.

> You already have a habit of cherry-picking example code that is as
> "Bart-unfriendly" as you can find.

Try testing your own C compiler on just about any codebase. You don't
have to look far for extreme examples.

> I don't have your experience, but I find that /very/ hard to believe.  I
> should imagine it's primarily a matter of working through the
> "translation phases" and "preprocessing directives" described in the C
> standards, step by step.

The C standard has very little to say about. I once found a very, very
long article which went into considerably more detail, now lost.

But even 1/3 through I decided that it was impossible.

In 2017 when I created my CPP, many compilers would give different
results with various edge cases of macros. Which were right and which
were wrong? You'd think there'd be a definitive reference for it.

Here's an example I've just found:

#include <stdio.h>
int main(void) {

#define FOO
#define BAR defined(FOO)
#if BAR
puts("BAR");
#else
puts("FOO");
#endif
}

Most compilers will display BAR; MSVC I think is the only one showing
FOO. (Some smaller compilers I tried on godbolt.org failed to compile it.)

Mine showed BAR (obviously!)

On 02/01/2024 20:11, Scott Lurndal wrote:
> Bart <bc@freeuk.cm> writes:

>> You're going to defend this to the death aren't you? Be funny if at some
>> point some GMP II was produced whose main new benefit was a vastly
>> simplified build!
>
> You still haven't provided a better system that accomplishes
> everthing the existing system does.

I need some basic information about what's what about in the 26MB of
content in 4000 files spread over 190 directories.

But it's clear that it's not interested in making things simple. (The
nearest they've come is with the 'mini-gmp' version. But since the
performance of that is on a par with my own library, I'll stick with
mine, which also has a higher spec.)

I have done this exercise with projects like LIBJPEG, LUA5.4 and
TCC0.9.27. Long ago I did it with SEED7.

Once I can extract the necessary info - IT ALWAYS COMES DOWN TO A LIST
OF FILES TO SUBMIT TO A COMPILER FGS - then I can whizz through it easily.

> Quit bitching about it and _do_ something about it.

Funnily enough, I did. I wrote my own library, which I know is always
available, and has some unique features, eg. it uses decimal, and has a
single integer/float type.

I once linked to a C port of it.

It's not fast, but it's mine and it's in my language. (It accounts for
12KB of my interpreter.)

> It's an open
> source system, you are free to contribute a new build system for
> it (which clearly needs to support all the capabilities of the
> existing system otherwise you'll never have your suggestions
> accepted).
>
> Don't, however, expect anyone to cater to you.

There must be one person on the planet who understands how to produce a
Windows DLL of this thing. And funnily enough, a single 64-bit DLL is
all any Windows user on the planet needs (that and either gmp.h or
language-neutral docs).

>>
>> I tried to build gmp today using WSL. The process took just under five
>> minutes. However, where and what is the output? For all the verbosity,
>> that simple fact is omitted.
>
> You presumably specified that on the ./configure with the --prefix
> option. Or did you forget to RTFM first?

I following these instructions:

--------------
Here are some brief instructions on how to install GMP. First you need to
compile. Since you're impatient, try this

./configure
make
make check <= VERY IMPORTANT!!

I did the first two line before looking for the binaries.

On 1/2/2024 12:24 PM, Bart wrote:
> On 02/01/2024 17:34, David Brown wrote:
>> On 02/01/2024 17:12, Bart wrote:
>
>>> X-macro are ugly. They are unreadable.
>>
>> Speaking as someone who has used them in real code, rather than
>> someone with a pathological hatred of macros and who prefers knee-jerk
>> reaction to their uses instead of applying a few minutes objective
>> thought, "x-macros" can make code significantly simpler, clearer, and
>> much easier to maintain correctly.
>
>
> I'm sorry, but I *DO* find them utterly impossible. This is a simple
> example from Stackoverflow of someone wanting to define a set of enums
> with an accompanying table, whose problem was in ensuring the two were
> kept in sync.
>
> The X-macro solution was this, adapted from the first answer here
> (https://stackoverflow.com/questions/6635851/real-world-use-of-x-macros); assume those functions are in scope:
>
> -------
>
> #define STATE_TABLE \
>         ENTRY(STATE0, func0) \
>         ENTRY(STATE1, func1) \
>         ENTRY(STATE2, func2) \
>         ENTRY(STATE3, func3) \
>
> enum
> {
> #define ENTRY(a,b) a,
>     STATE_TABLE
> #undef ENTRY
>     NUM_STATES
> };
>
> void* jumptable[NUM_STATES] =
> {
> #define ENTRY(a,b) b,
>     STATE_TABLE
> #undef ENTRY
> };
> -------
>
>
> With my feature, it is merely this:
>
>     global enumdata []ref void jumptable =
>         (state1, func1),        # comment 1
>         (state2, func2),
>         (state3, func3),        # comment 3
>         (state4, func4),
>     end
>
> Notice:
>
> (1) I don't need any of those weird macros.
>
> (2) I don't need those backslashes
>
> (3) I can add comments to any entry in the table.
>
> (4) The 'global' attribute means both enumeration names and the array
>     are exported to other modules. Doing the same in C is tricky.
>
> But I'm wasting my time because you are never going to admit my feature
> is superior to X-macros for this purpose.
>
> (The author of this example goes on to say how it can also be used to
> define a set of function prototypes. I can't do that with my feature.
> But then I don't need function prototypes!)
>
>>> At best, if someone has already done the hard work of setting up a
>>> working set of macros, then you will be able to see how to modify,
>>> add or delete entries.
>>
>> They are not hard.
>
> Maybe not for you, but it would take me ages to come up with the right
> incantations to make it work.
>
>>> For the purposes of creating parallel sets of enums and associated
>>> data, I use special syntax which makes for a clearer and simpler
>>> feature.
>>
>> And that is, obviously, utterly useless - because it is not C or even
>> a commonly supported extension.  Oh, and even if it /were/ part of C,
>> it would not help because that's not what I was doing.
>
> I've given an example of a use-case for C macros which have a special
> purpose feature in other languages. So of cause it's not in C.
>
>>>
>>> Have you ever considered that if C didn't have macros, or they
>>> weren't powerful, then it could have evolved superior, built-in
>>> alternatives?
>>>
>>
>> The C preprocessor is part of C - it is already built in.
>
> You missed my point. Take a tiny feature like being able to easily get
> the size of a fixed-length array. You commonly see macro like this:
>
>    #define LENGTH(a) (sizeof(a)/size(a[0]))
>
> What incentive is there to properly add a built-in way to do that, when
> it can be done, badly, and in 1000 different ways by each user, in a
> one-line macro?
>
> Another example is GETBIT(a, n).
>
>>> It wasn't a compiler limit - it was mine! The resulting expression
>>> was completely unreadable.
>>
>> I wonder if the code authors also found this expanded expression
>> unreadable.
>
> Look at the example I posted in reply to Blue-Maned_Hawk.
>
> In particular consider my last comment.
>
>
>> I guess not - because they used macros so that they could write it in
>> a clear and understandable way, and never have to look at the
>> expansion!  You don't seem to comprehend the point of macros at all.
>>
>>> In the end I resorted to looking at the AST as that was clearer than
>>> C source code.
>>>
>>
>> Why not just look at the code as written, if you want to understand it?
>
> In my case I was debugging my C compiler. Then you need to examine the
> actual expanded code in detail. Excessive use of macros makes that much
> harder.
>
> That example came from Lua 5.4, an interpeter whose performance on a par
> with my own product running from HLL-only code. That doesn't doesn't use
> deeply-nested macro like this, and it doesn't appear to suffer,.
>
>
>> Or would doing something that sensible put a damper on your rants?
>
> Look, I'm written a C preprocessor (I suspect you haven't). If I wanted,
> I could adapt it to work on my own languages.
>
> But I /don't/ want to. Obviously I see something undesirable about them
> (I don't like metaprogramming in general; people get too carried away
> with it and want to show off their skills).
>
> Why can't you accept that?
>
>
>>> Half my use-cases involve inline assembly.
>>
>> Why can't that be in inlined functions?
>
> That doesn't work in inline assembly.
>
>> Again, you are not showing that these limited macros have any benefits
>> compared to what is found in C,
>
> That's true. I can't write something like:
>
>      #define M a+b)*c
>
>      (M;
>
>
>>> Macros are a C language artefact, and what they expand to is
>>> arbitrary C syntax that can be meaningless elsewhere.
>>
>> Yes - C code is C code.  It is not Pascal, or Fortran, or Ada.  Should
>> this be a surprise?
>
> It's inconvenient. This is a macro from SDL2:
>
>   #define SDL_CompilerBarrier()   \
>   { SDL_SpinLock _tmp = 0; SDL_AtomicLock(&_tmp);
> SDL_AtomicUnlock(&_tmp); }

Why in the world would a compiler barrier need any atomics? I need to
study up on this wrt SDL.

>
> Rather than declaring a function which resides in a language-neutral
> DLL, it declares it here, in the form of actual C code.
>
> Even given a language with an FFI that is capable of calling external
> functions compiled as C, what are they supposed to do with this?
>
> That example was in a conditional block; I don't know the context. But
> here's a juicy one that is the result of an attempt to automatically
> translate the C SDL2 API to my syntax:
>
> global macro  SDL_FOURCC(A,B,C,D) =
> ((SDL_static_cast(Uint32,SDL_static_cast(Uint8,(A)))<<0)|(SDL_static_cast(Uint32,SDL_static_cast(Uint8,(B)))<<8)|(SDL_static_cast(Uint32,SDL_static_cast(Uint8,(C)))<<16)|(SDL_static_cast(Uint32,SDL_static_cast(Uint8,(D)))<<24))
>
> This also contains arbitrary C code; it needs a much more sophisticated
> tool than one that just does declaration. Basically a transpiler from
> C to the language one is writing bindinds for.
>
>
>> You already have a habit of cherry-picking example code that is as
>> "Bart-unfriendly" as you can find.
>
> Try testing your own C compiler on just about any codebase. You don't
> have to look far for extreme examples.
>
>> I don't have your experience, but I find that /very/ hard to believe.
>> I should imagine it's primarily a matter of working through the
>> "translation phases" and "preprocessing directives" described in the C
>> standards, step by step.
>
> The C standard has very little to say about. I once found a very, very
> long article which went into considerably more detail, now lost.
>
> But even 1/3 through I decided that it was impossible.
>
> In 2017 when I created my CPP, many compilers would give different
> results with various edge cases of macros. Which were right and which
> were wrong? You'd think there'd be a definitive reference for it.
>
> Here's an example I've just found:
>
>  #include <stdio.h>
>  int main(void) {
>
>   #define FOO
>      #define BAR defined(FOO)
>      #if BAR
>          puts("BAR");
>      #else
>          puts("FOO");
>      #endif
>  }
>
> Most compilers will display BAR; MSVC I think is the only one showing
> FOO. (Some smaller compilers I tried on godbolt.org failed to compile it.)
>
> Mine showed BAR (obviously!)
>
>

On 1/2/2024 1:00 PM, Chris M. Thomasson wrote:
> On 1/2/2024 12:24 PM, Bart wrote:
>> On 02/01/2024 17:34, David Brown wrote:
>>> On 02/01/2024 17:12, Bart wrote:
>>
>>>> X-macro are ugly. They are unreadable.
>>>
>>> Speaking as someone who has used them in real code, rather than
>>> someone with a pathological hatred of macros and who prefers
>>> knee-jerk reaction to their uses instead of applying a few minutes
>>> objective thought, "x-macros" can make code significantly simpler,
>>> clearer, and much easier to maintain correctly.
>>
>>
>> I'm sorry, but I *DO* find them utterly impossible. This is a simple
>> example from Stackoverflow of someone wanting to define a set of enums
>> with an accompanying table, whose problem was in ensuring the two were
>> kept in sync.
>>
>> The X-macro solution was this, adapted from the first answer here
>> (https://stackoverflow.com/questions/6635851/real-world-use-of-x-macros); assume those functions are in scope:
>>
>> -------
>>
>> #define STATE_TABLE \
>>          ENTRY(STATE0, func0) \
>>          ENTRY(STATE1, func1) \
>>          ENTRY(STATE2, func2) \
>>          ENTRY(STATE3, func3) \
>>
>> enum
>> {
>> #define ENTRY(a,b) a,
>>      STATE_TABLE
>> #undef ENTRY
>>      NUM_STATES
>> };
>>
>> void* jumptable[NUM_STATES] =
>> {
>> #define ENTRY(a,b) b,
>>      STATE_TABLE
>> #undef ENTRY
>> };
>> -------
>>
>>
>> With my feature, it is merely this:
>>
>>      global enumdata []ref void jumptable =
>>          (state1, func1),        # comment 1
>>          (state2, func2),
>>          (state3, func3),        # comment 3
>>          (state4, func4),
>>      end
>>
>> Notice:
>>
>> (1) I don't need any of those weird macros.
>>
>> (2) I don't need those backslashes
>>
>> (3) I can add comments to any entry in the table.
>>
>> (4) The 'global' attribute means both enumeration names and the array
>>      are exported to other modules. Doing the same in C is tricky.
>>
>> But I'm wasting my time because you are never going to admit my
>> feature is superior to X-macros for this purpose.
>>
>> (The author of this example goes on to say how it can also be used to
>> define a set of function prototypes. I can't do that with my feature.
>> But then I don't need function prototypes!)
>>
>>>> At best, if someone has already done the hard work of setting up a
>>>> working set of macros, then you will be able to see how to modify,
>>>> add or delete entries.
>>>
>>> They are not hard.
>>
>> Maybe not for you, but it would take me ages to come up with the right
>> incantations to make it work.
>>
>>>> For the purposes of creating parallel sets of enums and associated
>>>> data, I use special syntax which makes for a clearer and simpler
>>>> feature.
>>>
>>> And that is, obviously, utterly useless - because it is not C or even
>>> a commonly supported extension.  Oh, and even if it /were/ part of C,
>>> it would not help because that's not what I was doing.
>>
>> I've given an example of a use-case for C macros which have a special
>> purpose feature in other languages. So of cause it's not in C.
>>
>>>>
>>>> Have you ever considered that if C didn't have macros, or they
>>>> weren't powerful, then it could have evolved superior, built-in
>>>> alternatives?
>>>>
>>>
>>> The C preprocessor is part of C - it is already built in.
>>
>> You missed my point. Take a tiny feature like being able to easily get
>> the size of a fixed-length array. You commonly see macro like this:
>>
>>     #define LENGTH(a) (sizeof(a)/size(a[0]))
>>
>> What incentive is there to properly add a built-in way to do that,
>> when it can be done, badly, and in 1000 different ways by each user,
>> in a one-line macro?
>>
>> Another example is GETBIT(a, n).
>>
>>>> It wasn't a compiler limit - it was mine! The resulting expression
>>>> was completely unreadable.
>>>
>>> I wonder if the code authors also found this expanded expression
>>> unreadable.
>>
>> Look at the example I posted in reply to Blue-Maned_Hawk.
>>
>> In particular consider my last comment.
>>
>>
>>> I guess not - because they used macros so that they could write it in
>>> a clear and understandable way, and never have to look at the
>>> expansion!  You don't seem to comprehend the point of macros at all.
>>>
>>>> In the end I resorted to looking at the AST as that was clearer than
>>>> C source code.
>>>>
>>>
>>> Why not just look at the code as written, if you want to understand it?
>>
>> In my case I was debugging my C compiler. Then you need to examine the
>> actual expanded code in detail. Excessive use of macros makes that
>> much harder.
>>
>> That example came from Lua 5.4, an interpeter whose performance on a
>> par with my own product running from HLL-only code. That doesn't
>> doesn't use deeply-nested macro like this, and it doesn't appear to
>> suffer,.
>>
>>
>>> Or would doing something that sensible put a damper on your rants?
>>
>> Look, I'm written a C preprocessor (I suspect you haven't). If I
>> wanted, I could adapt it to work on my own languages.
>>
>> But I /don't/ want to. Obviously I see something undesirable about
>> them (I don't like metaprogramming in general; people get too carried
>> away with it and want to show off their skills).
>>
>> Why can't you accept that?
>>
>>
>>>> Half my use-cases involve inline assembly.
>>>
>>> Why can't that be in inlined functions?
>>
>> That doesn't work in inline assembly.
>>
>>> Again, you are not showing that these limited macros have any
>>> benefits compared to what is found in C,
>>
>> That's true. I can't write something like:
>>
>>       #define M a+b)*c
>>
>>       (M;
>>
>>
>>>> Macros are a C language artefact, and what they expand to is
>>>> arbitrary C syntax that can be meaningless elsewhere.
>>>
>>> Yes - C code is C code.  It is not Pascal, or Fortran, or Ada.
>>> Should this be a surprise?
>>
>> It's inconvenient. This is a macro from SDL2:
>>
>>    #define SDL_CompilerBarrier()   \
>>    { SDL_SpinLock _tmp = 0; SDL_AtomicLock(&_tmp);
>> SDL_AtomicUnlock(&_tmp); }
>
> Why in the world would a compiler barrier need any atomics? I need to
> study up on this wrt SDL.

Compiler barriers are completely different than memory barriers.

[...]

On 2024-01-02, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
> On Tue, 2 Jan 2024 18:16:36 -0000 (UTC), Kaz Kylheku wrote:
>
>> By the way, I'm not sure what system you are referring to by
>> "string-based macros", but in case you might be thinking of C
>> preprocessing, be advised that it's token-based.
>
> Now go learn what “homoiconicity” means.

Homoiconicity is a term that was introduced in the TRAC project
in the 1960's, referring to procedures being retained in source
form in the image, so they could be edited online.

(I actually made updates to the Wikipedia page on that.
Until fairly recently it contained a huge gaffe, whereby the term
"homoiconic" was misattributed to Doug McIlroy. This was due to
referencing an end note in a certain book, where the person writing the
article conflated two consecutive unrelated endnotes as being a
single note.)

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.

On 1/2/24 21:24, Bart wrote:
>
> You missed my point. Take a tiny feature like being able to easily get
> the size of a fixed-length array. You commonly see macro like this:
>
>    #define LENGTH(a) (sizeof(a)/size(a[0]))

And why is that bad? That's a real question.

--
+---------------------------------------------------------------------+
| https://wiki.interhacker.space/index.php?title=Techno-futilit%C3%A9 |
+---------------------------------------------------------------------+

Bart <bc@freeuk.cm> writes:
>On 02/01/2024 20:11, Scott Lurndal wrote:
>> Bart <bc@freeuk.cm> writes:
>
>>> You're going to defend this to the death aren't you? Be funny if at some
>>> point some GMP II was produced whose main new benefit was a vastly
>>> simplified build!
>>
>> You still haven't provided a better system that accomplishes
>> everthing the existing system does.
>
>I need some basic information about what's what about in the 26MB of
>content in 4000 files spread over 190 directories.
>
>But it's clear that it's not interested in making things simple. (The
>nearest they've come is with the 'mini-gmp' version. But since the
>performance of that is on a par with my own library, I'll stick with
>mine, which also has a higher spec.)
>
>I have done this exercise with projects like LIBJPEG, LUA5.4 and
>TCC0.9.27. Long ago I did it with SEED7.
>
>Once I can extract the necessary info - IT ALWAYS COMES DOWN TO A LIST
>OF FILES TO SUBMIT TO A COMPILER FGS - then I can whizz through it easily.
>
>
>> Quit bitching about it and _do_ something about it.
>
>Funnily enough, I did. I wrote my own library, which I know is always
>available, and has some unique features, eg. it uses decimal, and has a
>single integer/float type.
>
>I once linked to a C port of it.
>
>It's not fast, but it's mine and it's in my language. (It accounts for
>12KB of my interpreter.)
>
>
>> It's an open
>> source system, you are free to contribute a new build system for
>> it (which clearly needs to support all the capabilities of the
>> existing system otherwise you'll never have your suggestions
>> accepted).
>>
>> Don't, however, expect anyone to cater to you.
>
>There must be one person on the planet who understands how to produce a
>Windows DLL of this thing. And funnily enough, a single 64-bit DLL is
>all any Windows user on the planet needs (that and either gmp.h or
>language-neutral docs).
>
>>>
>>> I tried to build gmp today using WSL. The process took just under five
>>> minutes. However, where and what is the output? For all the verbosity,
>>> that simple fact is omitted.
>>
>> You presumably specified that on the ./configure with the --prefix
>> option. Or did you forget to RTFM first?
>
>
>I following these instructions:
>
>--------------
>Here are some brief instructions on how to install GMP. First you need to
>compile. Since you're impatient, try this
>
> ./configure
> make
> make check <= VERY IMPORTANT!!
>
>I did the first two line before looking for the binaries.

Try RTFM:

./configure --help

always useful.

On 02/01/2024 23:55, Scott Lurndal wrote:
> Bart <bc@freeuk.cm> writes:
>> On 02/01/2024 20:11, Scott Lurndal wrote:
>>> Bart <bc@freeuk.cm> writes:
>>
>>>> You're going to defend this to the death aren't you? Be funny if at some
>>>> point some GMP II was produced whose main new benefit was a vastly
>>>> simplified build!
>>>
>>> You still haven't provided a better system that accomplishes
>>> everthing the existing system does.
>>
>> I need some basic information about what's what about in the 26MB of
>> content in 4000 files spread over 190 directories.
>>
>> But it's clear that it's not interested in making things simple. (The
>> nearest they've come is with the 'mini-gmp' version. But since the
>> performance of that is on a par with my own library, I'll stick with
>> mine, which also has a higher spec.)
>>
>> I have done this exercise with projects like LIBJPEG, LUA5.4 and
>> TCC0.9.27. Long ago I did it with SEED7.
>>
>> Once I can extract the necessary info - IT ALWAYS COMES DOWN TO A LIST
>> OF FILES TO SUBMIT TO A COMPILER FGS - then I can whizz through it easily.
>>
>>
>>> Quit bitching about it and _do_ something about it.
>>
>> Funnily enough, I did. I wrote my own library, which I know is always
>> available, and has some unique features, eg. it uses decimal, and has a
>> single integer/float type.
>>
>> I once linked to a C port of it.
>>
>> It's not fast, but it's mine and it's in my language. (It accounts for
>> 12KB of my interpreter.)
>>
>>
>>> It's an open
>>> source system, you are free to contribute a new build system for
>>> it (which clearly needs to support all the capabilities of the
>>> existing system otherwise you'll never have your suggestions
>>> accepted).
>>>
>>> Don't, however, expect anyone to cater to you.
>>
>> There must be one person on the planet who understands how to produce a
>> Windows DLL of this thing. And funnily enough, a single 64-bit DLL is
>> all any Windows user on the planet needs (that and either gmp.h or
>> language-neutral docs).
>>
>>>>
>>>> I tried to build gmp today using WSL. The process took just under five
>>>> minutes. However, where and what is the output? For all the verbosity,
>>>> that simple fact is omitted.
>>>
>>> You presumably specified that on the ./configure with the --prefix
>>> option. Or did you forget to RTFM first?
>>
>>
>> I following these instructions:
>>
>> --------------
>> Here are some brief instructions on how to install GMP. First you need to
>> compile. Since you're impatient, try this
>>
>> ./configure
>> make
>> make check <= VERY IMPORTANT!!
>>
>> I did the first two line before looking for the binaries.
>
>
> Try RTFM:
>
> ./configure --help
>
> always useful.

As I said, I read the file called INSTALL and I did /exactly/ what it said.

You're telling me, when I'm questioning why I have to use build
instructions contained in a 10,000-page manual rather than a few sides
of A4 (that I can only use in a different country) that I should try
reading the guide to that manual!

You guys don't seem to get it.

The end-product will be a binary between 0.5 and 1.0MB. It is not a
170MB web browser.

I actually gave up being able to use this library years ago, so no
longer need it. If people really don't care about providing ready-to-use
libraries, then fuck 'em.

I now use my own library, which I can build into a DLL binary, like this:

c:\mx>mm -dll bignum
Compiling bignum.m------ to bignum.dll
Writing exports file to bignum.q

It takes 50msec. The secondary file it writes is a set of bindings to
use it from one of my other languages.

This stuff needs to be as effortless as this.

On Wed, 3 Jan 2024 02:08:40 +0000, Bart wrote:

> You guys don't seem to get it.

Another thing we do is, not to bother repeating work that others have
already done.

sudo apt-get install libgmp-dev

Job done.

On Wed, 3 Jan 2024 00:24:41 +0100, tTh wrote:

> On 1/2/24 21:24, Bart wrote:
>>
>>    #define LENGTH(a) (sizeof(a)/size(a[0]))
>
> And why is that bad? That's a real question.

Ignoring the typo? Not typesafe. If you pass something that it’s not
expecting, you will likely not get a nice, clear error message, but a
cryptic, not to say, irrelevant, one.

Also, would it be better as

#define LENGTH(a) (sizeof(a)/sizeof((a)[0]))

? Answers on a postcard, please.

On 2024-01-02, tTh <tth@none.invalid> wrote:
> On 1/2/24 21:24, Bart wrote:
>>
>> You missed my point. Take a tiny feature like being able to easily get
>> the size of a fixed-length array. You commonly see macro like this:
>>
>>    #define LENGTH(a) (sizeof(a)/size(a[0]))
>
> And why is that bad? That's a real question.

It fails miserably on pointers, and silently, if you don't have a newer
gcc that has a diagnostic specifically for this case.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.

On 1/1/2024 6:09 AM, David Brown wrote:
> On 31/12/2023 19:33, Scott Lurndal wrote:
>> Bart <bc@freeuk.cm> writes:
>>> On 31/12/2023 01:36, Lawrence D'Oliveiro wrote:
>>>> On Sat, 30 Dec 2023 01:58:53 +0000, Bart wrote:
>>>>
>>>>> So, why don't the vendors of the library do that exercise?
>>>>
>>>> Maybe because most of the “vendors” of proprietary libraries have gone
>>>> extinct. What we have now is “developers” and “contributors” to open-
>>>> source projects. And if you have a bright idea for how they can do
>>>> things
>>>> better, you are free to contribute it.
>>>
>>> I have plenty of ideas, but people are generally not interested.
>>
>> Perhaps they are not very good ideas, then....
>>
>> Frankly, your obsession with header files is puzzling.   99.9%
>> percent of C/C++ programmers don't care.
>
> Bart needs to care about the library header files when he is working on
> his C implementation, and it is understandable that he finds existing
> headers frustrating when he is trying to turn them into something his C
> implementation can use.  But you are absolutely correct that the huge
> majority of C programmers don't care what is in these headers.  So as I
> see it, the strange thing about Bart's view of library headers is not
> that /he/ is obsessed with them or frustrated by them, but that he
> apparently feels other people should also be bothered by them.
>
> The glibc (and other C library) developers have a responsibility to make
> headers that work correctly for C programmers, according to the C
> standards and their own documentation of extensions, and without
> significant measurable unnecessary inefficiency - beyond that, they can
> organise things in whatever way suits them and whatever way they find
> easiest.  They have no responsibility to make life easier for people
> making libraries, headers or compilers other than those they choose to
> work with.  Bart is right to think they /could/ have made it vastly
> easier to use their headers with other tools, such as his compiler - but
> wrong to think they /should/ have done so, and wrong to think that more
> than a tiny proportion of C programmers are bothered about it.
>

FWIW:
In my case, I am using a highly modified PDPCLIB (originally written, at
least in large part, by Paul Edwards). Looking at a few of the files, it
seems to identify as 2.01 from 2009 ...

My version has ended up changing a few parts:

stdio.h:
Somewhat modified, removed the "IBM mainframe" stuff, which was N/A for
my uses.

stdlib.h:
Switched over to my own malloc/free implementation, rewrote many of the
string and memory functions to "not be dead slow";

math.h:
Rewrote most of the math code, a lot of the original versions were slow
and/or prone to explode at random.
Mostly replaced a lot of the math functions with unrolled Taylor series
expansions and similar.

signal.h / locale.h / ...:
Added some of this (IIRC original versions were mostly no-op stubs).

Added some amount of C99 stuff and some C11 stuff.

Also added a lot of stuff from POSIX and similar as well.

One observation I have made is that often, the amount of code pulled in
from headers is larger than the amount of code present in a translation
unit, and so often "unity builds" are a net win for compilation time.

Though, the normal C library headers are not particularly big offenders
here, but more things like the OpenGL headers.

Or, in cases where I had crossed paths with "windows.h", the amount of
stuff this pulls in is "kinda absurd" (but, this is mostly N/A for my
current project; which makes no attempt to implement the Win32 API).

> C++ programmers (and C++ compiler writers) /do/ care a bit more about
> headers, though not the ones from the C standard library.  C++ headers
> are often very big and are a significant part of compile and build
> times.  Thus compilers often support pre-compiled headers, and one of
> the prime motivations of C++ modules in newer C++ standards is to be
> more efficient and cleaner than header files.
>

Yeah.

For plain C, things are a little more manageable.

Say, if I do (for compiling BGBCC via GCC):
time make -f Makefile.lnx
I get:
real 1m3.247s
user 0m59.688s
sys 0m3.297s

If I use Clang instead:
real 0m37.049s
user 0m33.938s
sys 0m2.000s

If compiling via MSVC, it is more around 20 seconds.

I have not tried to get my compiler to be self-hosting, but this is more
a case of me trying to compile stuff on my own platform being asking a
bit much at this stage (my compiler generally eats too much RAM, etc).

As noted, it doesn't really support x86 or ARM, since (as I see it)
these are served "well enough" by GCC/Clang/MSVC/etc.

If compiling GLQuake, my compiler seems to use around 230MB of RAM. With
the current version, with "compiler debug output" disabled, takes around
12 seconds on my Ryzen 2700X.

Assuming that compile time scales linearly with clock-speed, trying to
build GLQuake on a 50MHz CPU would take 15 minutes, but probably
significantly longer as it would also need to swap excessively.

These sorts of compile times seem likely unworkable.

Ideally, one would need a compiler that could compile something like
GLQuake in around 1 second (on a modern PC) at preferably under 40MB of RAM.

Note: For the GLQuake port, the compiler is compiling each C file as its
own translation unit. Also, this program is only 140 kLOC...

I guess, how quickly does GCC compile Quake?:
real 0m13.523s
user 0m7.781s
sys 0m5.281s

Though, this is the software version.

Hacking GLQuake into building:
real 0m17.777s
user 0m11.609s
sys 0m5.891s

Though, this isn't "actually working", just hacked stuff enough to get
it to build. This is on top of WSL.

....