Re: technology discussion → does the world need a "new" C ?

On 11/07/2024 16:58, David Brown wrote:

On 11/07/2024 13:22, bart wrote:

If the original array has type T[N], then the T is passed, but the N is lost. The [] is also lost:; it turns into *. But in C, that doesn't matter too much; it can still index that object!

 

(Here I'm talking about info attached to the parameter name; the type itself may still have that N. Have I mentioned that C is mess?)

 You've mentioned very clearly that your understanding of C is a mess.  C itself is quite simple here,

Not it isn't. The fact that I can do this:
     void F(vector a) {}          // typedef byte vector[100];
and get the type of 'a' as 'byte*', sizeof(a) as 8, sizeof(*a) as 1, but sizeof(vector) as 100, suggests all sorts of shenanigans.

and the rules are not hard to understand.

Ha ha ha! Of course you would say that. Let me try that same example:
   type vector = [50]u16                 # mix it up a little
    proc F(vector a)=
       println a.bytes                   # shows 100
#     println a^.bytes                  # error: not a pointer
       println vector.bytes              # shows 100
       println a.len, vector.len         # both show 50
    end
So the info for 'a' and 'vector' matches exactly, since after all 'vector' IS the type of 'a'!
I can't do the equivalent of *a, as 'a' is not a pointer. C gives me 3 different sizes for a byte-size; I can't even toss a coin to choose the right one.
I've stated several times now that the type system on my systems language is simple, consistent and orthogonal. Parameter passing is consistent from the language POV (despite the efforts of the ABI).
C's on the other hand, especially combined with its parameter passing, is a fucking mess. Everyone here secretly knows that; I don't know what they're trying to gain from pretending otherwise, and trying to put the blame on people who are calling it out.
I'm not trying to gloat here; I've use my type system for decades and it's nothing new or remarkable, just common sense. It's what C's should have been.

   type T = [4]int

 That is completely different.  Your language has a way to attach the size of an array into a type, and the characteristics follow that type declared in the function prototype.  That's fine, but it is a different thing entirely from saying that it is passed with the array itself. What you are doing here is much the same as wrapping a C array in a struct and passing that (as a value).

I'm defining a fixed-size array of 4 ints. It can be passed to a function expecting exactly that type, OR to a function expecting an unbounded array (OR to a function expecting a slice of 'int').
That's not possible with an array buried inside a struct. Which of course is not an array at all; the struct could have 50 fields, of, which could include half a dozen fixed arrays, some inside a nested struct.
/That/ is completely different.

Here my language uses the type []T (or [0]T). The empty bounds serve rhe same purpose as void* type: they will match any array bounds.

 OK, so you do the same as C but with a different syntax.  Presumably you think your syntax is vastly nicer than that of C, and will get your knickers in a twist if anyone says differently, but "niceness" is a matter of opinion.
 You are still not passing indefinitely sized arrays by reference.

Oh, what makes you say that?

>
In this case, while those 3 characteristics are still passed, the length one is not useful as it's always 0. Additional info is needed.
>
>

So perhaps your confusion here lies in a misunderstanding of how arrays as passed in your own language, and you have carried that confusion over to C.

>
Actually my language has a much tidier and more orthogonal type system, and there are no discontinuities such as expressions suddenly decaying to pointers whenever they threaten to yield an array type.
>
As such, it would much easier to teach, and could serve as a model against which C can be compared, and points of deviance noted.

 And yet, strangely, the world has been quite happy using C for half a century while I have yet to hear anyone say your language looks great.

I haven't mentioned syntax at all. I've talked about type systems and array passing, and how, when I enumerated 3 kinds of parameter passing in my language, C's parameter passing most matched either number (1) or (3) of mine depending on parameter type. (3) was pass-by-reference.

It combines the A and N parameters commonly passed to functions, into a composite object. It is not entirely different!
>

 Yes, it is.
 This thread would be so much simpler if you knew what you were talking about, or at least accepted that other people do.

I have some doubts that /you/ do!
A slice would be a natural addition to C's arrays. Passing a slice passes a pointer to the array data, just like C does anyway (the slice is passed by value; the data by reference!).
Applied to char arrays, it gives you counted strings.