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

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?
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.

 

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.

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!

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

 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.

These were my original comments on the subject made to DB:
DB:
 >. In C, there is no "pass by reference" or "return by reference".  It is all done by value.
BC:
 >Arrays are passed by reference:
 >  void F(int a[20]) {}
 >  int main(void) {
 >    int x[20];
 >    F(x);
 >  }
 > Although the type of 'a' inside 'F' will be int* rather than int(*)[20].
It was in reply to DB which appear to imply that arrays were passed by value. Obviously they're not passed by value, so what then? (Please, don't rerun the thread! This is where everyone jumped in.)