Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: bart <bc@freeuk.com>
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 11:04:13 +0100
Organization: A noiseless patient Spider
Lines: 115
Message-ID: <v6oamt$2d8nn$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>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Thu, 11 Jul 2024 12:04:14 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="92757c0b3eb137c08e71ba54311788f0";
	logging-data="2532087"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18fMBfS/4BP8v7UZ+CFbfgF"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:2tNpajY4G31fFlzMT8c+NVMrMzU=
In-Reply-To: <20240711115418.00001cdf@yahoo.com>
Content-Language: en-GB
Bytes: 5607

On 11/07/2024 09:54, Michael S wrote:
> On Thu, 11 Jul 2024 01:21:52 +0100
> bart <bc@freeuk.com> wrote:
> 
>> On 11/07/2024 00:01, Ben Bacarisse wrote:
>>> bart <bc@freeuk.com> writes:
>>>    
>>>> On 10/07/2024 14:32, Ben Bacarisse wrote:
>>
>>>> I still consider arrays in C to be 'passed' by a
>>>> mechanism which is near-indistinguishable from actual
>>>> pass-by-reference.
>>>
>>> I don't really care how you consider it, but I do care about how you
>>> misrepresent the facts in public.
>>>
>>> In another post you said that your language has pass by reference,
>>> and we also know you have implemented C.  Either you are just very
>>> confused and your language simply has call by value (after all, you
>>> think C has pass by reference), or you know that pass by reference
>>> in your language needs something from the implementation that was
>>> not needed when you implemented C.  I can't decide if you are
>>> confused or just lying.
>>
>>
>> The way it works in my language is very simple (this is what I do
>> after all):
>>
>>       type T = int
>>
>>       proc F(T x)=       # Pass by value
>>           println x.typestr
>>       end
>>
>>       proc G(ref T x)=   # Manual pass-by-reference
>>           println x^.typestr
>>       end
>>
>>       proc H(T &x)=      # Auto pass-by-reference
>>           println x.typestr
>>       end
>>
>>       proc main=
>>           T a
>>
>>           F(a)
>>           G(&a)
>>           H(a)
>>       end
>>
>> I've written 3 functions using pass-by-value, pass-by-value emulating
>> pass-by-reference, and actual pass-by-reference.
>>
>> The G function and the call to G show what the compiler has to add
>> when it processes function H: address-of ops and derefs. The cost is
>> a single & in the parameter list to get that convenience.
>>
>> This programs works just the same if T was changed to an array:
>>
>>       type T = [4]int
>>
>> (The output is 3 lots of '[4]i64' instead of 3 lots of 'i64'; 'int'
>> is an alias for int64/i64.)
>>
>> This is regular and orthogonal, a complete contrast to C even though
>> both languages supposedly operate at the same level.
>>
>> The behaviour of F, when written in C, is like my F function when T
>> is an int (obviously the C won't have '.typestr').
>>
>> But when T is an array, its behaviour is more like that of my H
>> function.
>>
>> So, my remark about arrays in C being passed by reference is
>> understandable.
>>
> 
> 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.

In that regard, it's no different from the C: my array by-ref and C's 
alledged by-ref both cannot determine the array length solely from the 
parameter.

(In my language, attempts to get the length yields 0, which makes sense 
as the parameter's bounds are zero. In C, it will yield the size of the 
pointer.)

But when the array IS bounded, then in C:

   typedef byte vector[4];

   void F(vector a) {
       printf("%zu\n", sizeof(a));
       printf("%zu\n", sizeof(vector));
   }

The first printf shows 8 (the pointer size); the second shows 4 (the 
array size). So it /can/ access the bounds.

(For unbounded arrays, my language offers an alternative: slices, which 
contain their length. This is available whatever the calling mechanism.)