Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Michael S <already5chosen@yahoo.com>
Newsgroups: comp.lang.c
Subject: Re: technology discussion =?UTF-8?Q?=E2=86=92?= does the world need
 a "new" C ?
Date: Thu, 11 Jul 2024 13:25:19 +0300
Organization: A noiseless patient Spider
Lines: 122
Message-ID: <20240711132519.00004a28@yahoo.com>
References: <v66eci$2qeee$1@dont-email.me>
	<v6ard1$3ngh6$4@dont-email.me>
	<v6b0jv$3nnt6$1@dont-email.me>
	<87h6d2uox5.fsf@nosuchdomain.example.com>
	<v6d779$6rk5$2@dont-email.me>
	<v6e76u$c0i9$1@dont-email.me>
	<v6esqm$fian$2@dont-email.me>
	<v6f7vg$hgam$1@dont-email.me>
	<20240707164747.258@kylheku.com>
	<v6gl83$s72a$1@dont-email.me>
	<v6h8ao$ur1v$1@dont-email.me>
	<v6jhk3$1drd6$1@dont-email.me>
	<v6jiud$1dsjb$1@dont-email.me>
	<877cdur1z9.fsf@bsb.me.uk>
	<v6joi4$1epoj$1@dont-email.me>
	<871q42qy33.fsf@bsb.me.uk>
	<v6k6i0$1h4d3$1@dont-email.me>
	<87ed82p28y.fsf@bsb.me.uk>
	<v6m03l$1tf05$1@dont-email.me>
	<87r0c1nzjj.fsf@bsb.me.uk>
	<v6m716$1urj4$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>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Injection-Date: Thu, 11 Jul 2024 12:24:55 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="cc2ba001c5d2368b495ec9c7cf5e7c33";
	logging-data="2492964"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+TYcuDFlpt/GZlOd8YRqGw1X61GHUP5fc="
Cancel-Lock: sha1:LahQrF74zvUyd7wEqPwLorKcMoQ=
X-Newsreader: Claws Mail 3.19.1 (GTK+ 2.24.33; x86_64-w64-mingw32)
Bytes: 6048

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.