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

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