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

On 11/07/2024 11:41, David Brown wrote:

On 11/07/2024 12:04, bart wrote:

On 11/07/2024 09:54, Michael S wrote:

 

No, it isn't.
If [in C] it was possible to pass arrays to functions, either by value
or by reference, then callee would know the length of passed array. As
it is, callee does not know it.

>

The length can be passed in a separate parameter, but then it does not
have to be the same as an original.

>
That's rather specious. In my language (probably in C too), most passed arrays are unbounded, allowing the same function to work with arrays of different sizes.
>
So that would need a separate Length parameter, even using by-reference.

 No.
 Like any object, an array has data, and characteristics including the type of the elements, and for an array, the length of the array.  If you pass an object, by reference or by value, the receiver (function parameter, or caller if we are talking about return values) gets the characteristics as well as the data.

In C, if you write code that looks a bit like it is passing an array, the object's characteristics don't follow along with it

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!
So 1 out of 3 characteristics make it into the callee. (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?)

- therefore you are not passing the array.  If in your language, the characteristics also do not follow, as part of the parameter, then your language cannot pass arrays either.

If the original type is [N]T, then all 3 of those characteristics are accessible in the callee, and are characteristics of both the type, and the parameter name:
   type T = [4]int
   proc F(T x)=
       println T.typestr, T.len, T.bytes
       println x.typestr, x.len, x.bytes, x[1].typestr
   end
This shows:
   [4]i64 4 32
   [4]i64 4 32 i64
(It also reports an error if I attempt to pass a [5]int type; the C version won't care. You don't need to explain why.)

If you need to have a separate manual length parameter, then your language is doing the same as C - you are passing a pointer by value without the full object information.

This was the problem with the original Pascal: arrays of different fixed sizes were strictly different types. You couldn't write a function that took either an int[10] or int[20], or some array allocated at runtime.
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.
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.
(I'm sure there are mainstream languages that could serve that purpose too! But mostly they are too different.)

A slice is presumably an object that encapsulates a pointer to data and size information - a struct.  It might give a nice syntax in your language, but it is a different concept entirely.

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