Path: ...!news.nobody.at!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Ben Bacarisse <ben@bsb.me.uk>
Newsgroups: comp.lang.c
Subject: Re: technology discussion =?utf-8?Q?=E2=86=92?= does the world need
 a "new" C ?
Date: Fri, 16 Aug 2024 01:08:15 +0100
Organization: A noiseless patient Spider
Lines: 200
Message-ID: <87sev5s51s.fsf@bsb.me.uk>
References: <v66eci$2qeee$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> <v6ovfc$2hcpf$1@dont-email.me>
	<v6p4hf$2icph$1@dont-email.me> <v6qgpu$2t6p7$3@dont-email.me>
	<v6r33m$30grj$1@dont-email.me> <20240712154252.00005c2f@yahoo.com>
	<86o7717jj1.fsf@linuxsc.com> <v6ti10$3gru4$1@dont-email.me>
	<v78af7$1qkuf$1@dont-email.me> <20240717163457.000067bb@yahoo.com>
	<v78piu$1su4u$1@dont-email.me> <86a5hep45h.fsf@linuxsc.com>
	<v9ktep$v5sk$1@dont-email.me> <87y14xsvnh.fsf@bsb.me.uk>
	<v9l95b$10ogv$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain
Injection-Date: Fri, 16 Aug 2024 02:08:15 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="e2d864991417c23f00812fb2ef3e1b2b";
	logging-data="1199306"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+uZ62NT/6ByFGQGBgrX0bKSh+zg/nDVJ0="
User-Agent: Gnus/5.13 (Gnus v5.13)
Cancel-Lock: sha1:96dBFwVBNdygU9mUD2rALBYCifE=
	sha1:bz4r3YCk4iG+3H+RMwX62O1mXLM=
X-BSB-Auth: 1.7bac07d339c46b84d580.20240816010815BST.87sev5s51s.fsf@bsb.me.uk
Bytes: 9652

Bart <bc@freeuk.com> writes:

> On 15/08/2024 15:33, Ben Bacarisse wrote:
>> Bart <bc@freeuk.com> writes:
>> 
>>> On 15/08/2024 09:43, Tim Rentsch wrote:
>>>> Bart <bc@freeuk.com> writes:
>
>>>>                           C call-by-value         call-by-reference
>>>>                           ===============         =================
>>>>     at call:
>>>>
>>>>       (array argument)    F(A)                    H(A)
>>>>
>>>>       (pointer argument)  F(p)                    (disallowed)
>>>
>>> My posts were about passing *arrays* and the fact that C's pass-by-value
>>> was remarkably similar to pass-by-reference.
>> Which is why, presumably, you didn't show the differences.  Your
>> post was all polemic not part of a collegiate discussion of the
>> similarities and differences.
>> 
>>> However your entry for pointers is not correct:
>> No, the entry is correct.  H(p) would be (is?) disallowed when H's
>> parameter is a reference to an array.
>
> Sorry, what language does the right-hand column pertain to? /Any/ language
> that has call-by-reference, or Tim's hypthetical language?

Tim said that case was "disallowed".  You call that an error on his
part.  What language did you have in mind that permits such a gross
warping of types?  I would describe /any/ language that allowed it as
having a design error.

> Or any that could be used to prove him right?
>
> In general there is no reason, in a language with true call-by-reference,
> why any parameter type T (which has the form U*, a pointer to anything),
> cannot be passed by reference. It doesn't matter whether U is an array type
> or not.

I can't unravel this.  Take, as a concrete example, C++.  You can't pass
a pointer to function that takes an array passed by reference.  You can,
of course, pass a pointer by reference, but that is neither here nor
there.
 
>>> you can pass pointers by
>>> reference (in C, it means passing a T** type instead of T* to emulate
>>> that).
>> H's parameter is /not/ what you claim "emulates" a reference to a
>> pointer -- it's a hypothetical reference to an array.
>
> In my original post it was G() that was C emulating pass-by-reference.
>
> It wasn't stated that p was an array pointer, only pointer, but it doesn't
> make any difference in H which we can assume is not C, and therefore
> doesn't have C's hangups about arrays and pointers.

The whole point if Tim's post was to point out how call-by-reference
would be significantly different to what C has right now.  That requires
imaging "C with call-by-reference".

>> Maybe you missed what Tim was doing.  He is showing a fuller comparison
>> for one F and one H.  A different function could, in this hypothetical
>> C with call-by-reference, be passed a pointer, but then it could not be
>> passed an array.
>
> Neither of you have explained this well. Are you both projecting C's
> craziness with arrays and pointers onto this hypothetical language?
>
> If so, then if this fantasy language has true pass-by-reference, then let
> it have real value-arrays too!

It might, but it would be closer to C if it did not.  And C++ is not a
fantasy language but it has reference parameters that behave as
illustrated.

>>>>       (null argument)     F(0)                    (disallowed)
>>>
>>> Pass-by-reference necessarily requires an lvalue at the call-site
>> Yes, that is one of the differences you failed to illustrate.
>
> I illustrated some conveniences which C's array-passing idiom which match
> those of true pass-by-reference.
>
>
>>> since it effectively applies & to the argument.
>> No.  Passing a reference is /not/ like using & to pass a pointer.
>
> Funny, in my language that is EXACTLY how it is implemented. Instead of my
> writing:
>
>   F(&x) and in F having to write: *x
>
> you instead write:
>
>   F(x) and in F you write: x

Your whole point (which to some extent I accept) is that what the user
writes is what matters.  Passing a reference is /not/ like using & to
pass a pointer.

> So it will insert & and * operators for you. Why,  how would /you/ do it?
> (I'm talking about this level of language; higher level ones might do
> everthing with references anyway, and might not have & or * operators.)
>
>
>
>>>>     inside function:
>>>>
>>>>       (access)            A[i]                    A[i]
>>>>
>>>>       (update)            A[i] = ...              A[i] = ...
>>>>
>>>>       sizeof A            (pointer size)          (array size)
>>>
>>> That's one of the small differences. But you only get the array size in a
>>> language where the array type includes its length. Otherwise, you only get
>>> it if it's part of the parameter type.
>>>
>>>>       A++                 (changes A variable)    (disallowed)
>>>
>>> (In my language ++A is allowed. I'm not sure why, it's likely a bug.)
>> In the hypothetical C with call-by-reference, it's another difference
>> you chose not to show.
>
> Yes, as I said, I concentrate on the ones which allowed you to write F(A),
> and A[i] inside F, just like pass-by-reference, rather than F(&A), and
> (*A[i]) inside F. Did I claim it was full by pass-by-reference?
>
>>>>       A = (new value)     (changes A variable)    (disallowed)
>>>
>>> This is allowed too in my language, if the array has a fixed size. It
>>> reassigns the whole array.
>> Your language (for which we have no reference material) is beside the
>> point.  This is another difference you failed to point out in your
>> comparison
>
> It doesn't matter; any call-by-reference worth its salt will allow you to
> change variables in the caller. That's half the point it!

C with call-by-reference should treat array references just like C
arrays.  A reference should behave like the thing it references.

> C doesn't have A=B syntax for arrays, but it can do memcpy for the same
> effect.
>
>
>> 
>>> In C you can't do A = B for other reasons, since arrays aren't manipulated
>>> by value.
>> One way or another, this is a difference you failed to illustrate.  If
>> this hypothetical C is very close to C then the difference is as Tim
>> posted.  But in a another quasi-C that permits array assignment there
>> would still be a difference: the pointer assignment would be disallowed
>> but the array assignment (by reference) would be permitted.
>
> What pointer assignment? You're mixing actual C with fantasy C. You can't
> do that: if you add array assignment to C, then it changes everything.

Indeed, but you brought up assignable arrays in your language so I
wanted to show how, even in such an extended C, it remains a difference
you were glossing over.

>> So why did you give only one side of the comparison?  You have nothing
>> to lose by being open about the differences if your objective is an
>> open, collegiate discussion of C.  By presenting a polemic, you make the
>> whole exchange more antagonistic than it needs to be.
>
========== REMAINDER OF ARTICLE TRUNCATED ==========