Path: ...!weretis.net!feeder8.news.weretis.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: David Brown <david.brown@hesbynett.no>
Newsgroups: comp.lang.c
Subject: =?UTF-8?Q?Re=3A_technology_discussion_=E2=86=92_does_the_world_need?=
 =?UTF-8?B?IGEgIm5ldyIgQyA/?=
Date: Thu, 11 Jul 2024 17:58:34 +0200
Organization: A noiseless patient Spider
Lines: 163
Message-ID: <v6ovfc$2hcpf$1@dont-email.me>
References: <v66eci$2qeee$1@dont-email.me> <v6ard1$3ngh6$4@dont-email.me>
 <v6b0jv$3nnt6$1@dont-email.me> <87h6d2uox5.fsf@nosuchdomain.example.com>
 <v6d779$6rk5$2@dont-email.me> <v6e76u$c0i9$1@dont-email.me>
 <v6esqm$fian$2@dont-email.me> <v6f7vg$hgam$1@dont-email.me>
 <20240707164747.258@kylheku.com> <v6gl83$s72a$1@dont-email.me>
 <v6h8ao$ur1v$1@dont-email.me> <v6jhk3$1drd6$1@dont-email.me>
 <v6jiud$1dsjb$1@dont-email.me> <877cdur1z9.fsf@bsb.me.uk>
 <v6joi4$1epoj$1@dont-email.me> <871q42qy33.fsf@bsb.me.uk>
 <v6k6i0$1h4d3$1@dont-email.me> <87ed82p28y.fsf@bsb.me.uk>
 <v6m03l$1tf05$1@dont-email.me> <87r0c1nzjj.fsf@bsb.me.uk>
 <v6m716$1urj4$1@dont-email.me> <87ikxconq4.fsf@bsb.me.uk>
 <v6n8iu$24af0$1@dont-email.me> <20240711115418.00001cdf@yahoo.com>
 <v6oamt$2d8nn$1@dont-email.me> <v6oct4$2djgq$2@dont-email.me>
 <v6of96$2ekb0$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Thu, 11 Jul 2024 17:58:37 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="9ace034eeab6e27c960914de7518aa3f";
	logging-data="2667311"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19w/uTkrqtGatDa7EKfZzg8M+CsKgoT+us="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:Q0OKFcvWKQwHpJD9QQxb06sVdqU=
Content-Language: en-GB
In-Reply-To: <v6of96$2ekb0$1@dont-email.me>
Bytes: 8713

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.