Re: question about linker

On Fri, 29 Nov 2024 13:33:30 +0000
Bart <bc@freeuk.com> wrote:

On 29/11/2024 12:28, Michael S wrote:

On Fri, 29 Nov 2024 11:04:16 +0000
Bart <bc@freeuk.com> wrote:
 

>
My original point was trying to address why 'const' as used in C
might be confusing. I was trying to compare how non-mutable
variables are designated in other languages. There it's a keyword
that is part of the declaration syntax, not the type syntax.
 

 
I don't see your point.
How 'mut' in Rust is different from 'const' in C except for having
opposit polarity?
How 'readonly' in C# is different from 'const' in C? 

 
I'm not familiar enough with those languages. Can mut or readonly be
used multiple times within a single type specification? Can they be
used in a context where no identifier is involved?
 
If so then they work like C's const does.
 
(My own attempts at 'readonly' used keywords that applied to
definitions only, not to types:
 
   const [T] a = x            # x must be compile-time expr
   let    T  b := y           # runtime y but b can't be reassigned
   [var]  T  c [:= z]         # normal fully mutable variable
   static T  d  = w           # compile/load-time expr
 
I've dropped support for explicit 'let'; it tends to be used
internally for implicit assign-once variables like loop indices; or
fully readonly data like tables.)

 

I suggested that C is confusing because 'const' looks as though
it's like the former, but it's part of the latter. Which also
means you can have multiple 'const' in a declaration (putting
asided repeated 'consts').
 

 

IMHO, any way to mix more than one 'modifier' (not in C standard
meaning of the word, but in more general meaning) is potentially
confusing. It does not matter whether modifier is 'const' or '*' or
[] or (). 

 
Constructing an abitrary type specification by chaining together
'modifiers' is not confusing by itself:
 
   Pointer to array 10 of const pointer to int x
   x: Pointer to array 10 of const pointer to int
 
It IS confusing the way C does it, because:
 
* It breaks it up into a base-type ...
 
* ... plus modifiers that go before any identifier ...
 
* ... plus modifiers that go after the identifier
 

Yes, presence of both pre and post 'modifiers' makes things much
worse.

* It allows a list of variable names in the same declaration to each
   have their own modifiers, so each can be a totally different type
 

Not in every context. It is not allowed in function prototypes. Even
when it is allowed, it's never necessary and avoided by majority of
experienced programmers.
I'd guess, TimR will disagree with the last part.

* This means the type of a variable in a list can be split up into
three disjoint parts
 
* It has 'const' that can go before OR after a basic type, or after
   a modifier that goes before an identifier, but not before or after
a modifier that goes after an identifier (so no const array/function)
 
* The 'root' of the type, what would go on the left if expressed in
   LTR form, is somewhere in the middle of each typespec, starting
   near the identifier ...
 
* ... except that often there is no identifier, then you have to apply
   an algorithm to figure out what it means
 
* There are precedence rules which means often having to use
parentheses to get the typespec that you want:  T*A[] is different
from T(*A)[].
 
Apart from these minor points, typespecs in C are simple!
 
But if C types were LTR, and not split up, then figuring out whether
the variable you're declaring was readonly is easy: there would be
'const' on the extreme left.
 
(I would also impose a rule that a 'const' on the left could not
appear within a typedef, only at the point the type is used.)