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

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

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!

In C, writing a function parameter as an array is equivalent to writing it as a pointer to an element of the array.  And if you use an array expression as an argument when calling a function, it is implicitly converted to a pointer to its first element.
And then since in C the subscript operator is just a way of writing pointer arithmetic, of course you can use that pointer to access the data in the array.  But you can't use it to get any information about the array itself, such as its length.

 So 1 out of 3 characteristics make it into the callee.

Right - you get the type of the elements pointed to.
With pass by reference, you'd expect the fact that it is an array to pass through, along with the size of the array.  That's what you get when you use a language that supports pass by reference, and supports passing arrays, such as using C++ with std::array<> types.  (C++ does not support passing C-style arrays to or from functions.)

(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, and the rules are not hard to understand. (You might disagree with the choice of rules, or the syntax for them - and I think most C users have some disagreements there.  But that doesn't mean they don't understand them.)

 

- 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

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).  You are just moving the goalposts in an attempt to claim you were not wrong earlier.

    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.
 

And in C you can put a fixed size array in a struct (or a union) to declare a new type, as that is how you make new types in C.  ("typedef", despite its name, does not define types - it merely defines type aliases.)

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.

 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. (But to be fair I have said in the past that there are some features of it that I like.)

 (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!
 

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.