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

On Thu, 11 Jul 2024 11:04:13 +0100
bart <bc@freeuk.com> wrote:

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

It can access the bounds of type vector. But parameter a is not of type
vector despite the declaration.
And yes, I think that C would have been better language if the code as
above was a syntax error. But this battle was lost when I was in the
middle school.