Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Michael S 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: <87h6d2uox5.fsf@nosuchdomain.example.com> <20240707164747.258@kylheku.com> <877cdur1z9.fsf@bsb.me.uk> <871q42qy33.fsf@bsb.me.uk> <87ed82p28y.fsf@bsb.me.uk> <87r0c1nzjj.fsf@bsb.me.uk> <87ikxconq4.fsf@bsb.me.uk> <20240711115418.00001cdf@yahoo.com> 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 wrote: > On 11/07/2024 09:54, Michael S wrote: > > On Thu, 11 Jul 2024 01:21:52 +0100 > > bart wrote: > > > >> On 11/07/2024 00:01, Ben Bacarisse wrote: > >>> bart 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.