Re: question about linker

On 30/11/2024 15:57, David Brown wrote:

On 29/11/2024 19:26, Bart wrote:

>
C's syntax allows a 14-parameter function F to be declared in the same statement as a simple int 'i'.

 And the laws of physics allow me to drop a 20 kg dumbbell on my toe. That does not mean that anyone thinks it is a good idea.

Who said it's a good idea? I merely said that C allows such disparate types in declarations. You disagree that they are different types, while at the same time saying it's a bad idea to mix them in the same declaration!

I'd say that F and i are different types! (Actually I wouldn't even consider F to be type, but a function.)

 Functions have types in most typed languages, including C.
 And yes, F and i are different types - but they are related types.  Use the declared identifier in an expression of a form matching what you wrote in the declaration, and the expression will have type "int". That's how C's declarations work.

That's not how people's minds work. If you declare A, B, and C, then what is important is the types of A, B, and C, not what might yielded as they result of some expression.
People can write A in an expression using all the modifiers specified for it, or they can write with none or some of the modifiers, or they might write &A; generally they will yield different types.
If I write this
   int *A, B[10], C(int);
My compiler tells me that:
   A is a local variable with type 'ref i32' (expressed in other syntax)
   B is a local variable with type '[10]i32'
   C is a function with return type of 'i32', taking one unnamed
     parameter of type 'i32'.
(Interestingly, it places C into module scope, so the same declaration can also create names in different scopes!)
However writing:
   A; B; C;
creates expressions with types 'ref i32', 'ref i32', and 'ref proc(i32)i32' according to C rules. All quite different from your claim that they all yield 'int' (while C makes the scalar A and array B the same type!).
So the key types are what are specified in the symbol table. And those are different and incompatible.
BTW here are A, B, C in my syntax:
    ref i32 A
    [10]i32 B
    proc(i32)i32 C
(The last is a function declaration, which only exist for FFI functions; it can only appear in an 'importdll' block.)
I don't think anyone outside the C world would consider even A and B as having related types - int vs array - let alone C. Yet you are claiming this.

Really, most of this is pretty straightforward.  No one is asking you to /like/ the rules of C's declarations (I personally dislike that a single declaration can be used for different types, even if they are related). But /please/ stop pretending it's difficult to understand.

I keep saying that my language is easier than this with simpler rules. That makes C harder. It also makes it more errorprone. It can make it more confusing. That is just the truth.

>

C allows this, but I personally would be happier if it did not.  As Michael says below, most serious programmers don't write such code.

>
It doesn't matter. If you're implementing the language, you need to allow it.

 I am not implementing the language.  No one else here is implementing it.  You have, apparently, implemented at least some of the language while being completely incapable of understanding it.

And you seem utterly incapable of understanding that A implementing some complicated and badly designed system X doesn't mean that A becomes an expert in using X, or suddenly thinks of it as simple and well-designed.
Quite the opposite in fact, since they get to see the nitty-gritty details, and especially where people have papered over the cracks.
They will also get to see a vast amount of badly written code that breaks all the rules, compared to B who not only uses just their prefered subset of X, but additional systems Y and Z to hide some of the problems.

/That/ is how you solve problems with syntax that can be abused to write unclear code.

You solve it by fixing the language. If you can't fix the language then you use a strong workaround, such as a new syntax wrapper around it.
 >  The C newbie will thank
 > you for the lesson, and move on to write C code without writing such
 > mixed declarations.
You can't give such a lesson to everyone, so there will still be a million programmers who pick up bad habits, not helped by the tools they use being lax.

With the kind of C I would write, you could discard everything after C99, and even half of C99, because the subset I personally use is very conservative.
>

 You say that as though you think it is a good thing - it is not.

Why?
I reckon people will have an easier type understanding and working with my code than yours. It will at least work with more compiles.