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

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.

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

I'm not sure why you bring this up.  I think you have subsequently
acknowledged that arrays are not passed by reference in C (nothing is)
so if you don't want to rerun the thread, what does this old exchange
add?  And of your question "so what then?" is not rhetorical, what was
wrong with the answers you got before (including from me)?

--
Ben.