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 11:54:18 +0300 Organization: A noiseless patient Spider Lines: 84 Message-ID: <20240711115418.00001cdf@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> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Injection-Date: Thu, 11 Jul 2024 10:53:53 +0200 (CEST) Injection-Info: dont-email.me; posting-host="cc2ba001c5d2368b495ec9c7cf5e7c33"; logging-data="2492964"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/77ww5+0ctTw26Q3a+jcFsM4EAZZmP/nQ=" Cancel-Lock: sha1:cXnIEsIm0mu9izf72R4M2xUkqyA= X-Newsreader: Claws Mail 3.19.1 (GTK+ 2.24.33; x86_64-w64-mingw32) Bytes: 4434 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.