Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: bart <bc@freeuk.com>
Newsgroups: comp.lang.c
Subject: =?UTF-8?Q?Re=3A_technology_discussion_=E2=86=92_does_the_world_need?=
 =?UTF-8?B?IGEgIm5ldyIgQyA/?=
Date: Thu, 11 Jul 2024 18:25:03 +0100
Organization: A noiseless patient Spider
Lines: 132
Message-ID: <v6p4hf$2icph$1@dont-email.me>
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> <v6oct4$2djgq$2@dont-email.me>
 <v6of96$2ekb0$1@dont-email.me> <v6ovfc$2hcpf$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Thu, 11 Jul 2024 19:25:04 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="92757c0b3eb137c08e71ba54311788f0";
	logging-data="2700081"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+21lXdCwWxCapvc55IhoYv"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:FIAw5J7DHXo/aUM2FKQpNxvMxUI=
In-Reply-To: <v6ovfc$2hcpf$1@dont-email.me>
Content-Language: en-GB
Bytes: 7126

On 11/07/2024 16:58, David Brown wrote:
> On 11/07/2024 13:22, bart wrote:

>> If the original array has type T[N], then the T is passed, but the N 
>> is lost. The [] is also lost:; it turns into *. But in C, that doesn't 
>> matter too much; it can still index that object!
> 

>> (Here I'm talking about info attached to the parameter name; the type 
>> itself may still have that N. Have I mentioned that C is mess?)
> 
> You've mentioned very clearly that your understanding of C is a mess.  C 
> itself is quite simple here, 

Not it isn't. The fact that I can do this:

     void F(vector a) {}          // typedef byte vector[100];

and get the type of 'a' as 'byte*', sizeof(a) as 8, sizeof(*a) as 1, but 
sizeof(vector) as 100, suggests all sorts of shenanigans.

>and the rules are not hard to understand. 

Ha ha ha! Of course you would say that. Let me try that same example:

   type vector = [50]u16                 # mix it up a little

    proc F(vector a)=
       println a.bytes                   # shows 100
#     println a^.bytes                  # error: not a pointer
       println vector.bytes              # shows 100
       println a.len, vector.len         # both show 50

    end

So the info for 'a' and 'vector' matches exactly, since after all 
'vector' IS the type of 'a'!

I can't do the equivalent of *a, as 'a' is not a pointer. C gives me 3 
different sizes for a byte-size; I can't even toss a coin to choose the 
right one.

I've stated several times now that the type system on my systems 
language is simple, consistent and orthogonal. Parameter passing is 
consistent from the language POV (despite the efforts of the ABI).

C's on the other hand, especially combined with its parameter passing, 
is a fucking mess. Everyone here secretly knows that; I don't know what 
they're trying to gain from pretending otherwise, and trying to put the 
blame on people who are calling it out.

I'm not trying to gloat here; I've use my type system for decades and 
it's nothing new or remarkable, just common sense. It's what C's should 
have been.

>>    type T = [4]int
> 
> That is completely different.  Your language has a way to attach the 
> size of an array into a type, and the characteristics follow that type 
> declared in the function prototype.  That's fine, but it is a different 
> thing entirely from saying that it is passed with the array itself. What 
> you are doing here is much the same as wrapping a C array in a struct 
> and passing that (as a value).

I'm defining a fixed-size array of 4 ints. It can be passed to a 
function expecting exactly that type, OR to a function expecting an 
unbounded array (OR to a function expecting a slice of 'int').

That's not possible with an array buried inside a struct. Which of 
course is not an array at all; the struct could have 50 fields, of, 
which could include half a dozen fixed arrays, some inside a nested struct.

/That/ is completely different.


>> Here my language uses the type []T (or [0]T). The empty bounds serve 
>> rhe same purpose as void* type: they will match any array bounds.
> 
> OK, so you do the same as C but with a different syntax.  Presumably you 
> think your syntax is vastly nicer than that of C, and will get your 
> knickers in a twist if anyone says differently, but "niceness" is a 
> matter of opinion.
> 
> You are still not passing indefinitely sized arrays by reference.

Oh, what makes you say that?


>>
>> In this case, while those 3 characteristics are still passed, the 
>> length one is not useful as it's always 0. Additional info is needed.
>>
>>
>>> So perhaps your confusion here lies in a misunderstanding of how 
>>> arrays as passed in your own language, and you have carried that 
>>> confusion over to C.
>>
>> Actually my language has a much tidier and more orthogonal type 
>> system, and there are no discontinuities such as expressions suddenly 
>> decaying to pointers whenever they threaten to yield an array type.
>>
>> As such, it would much easier to teach, and could serve as a model 
>> against which C can be compared, and points of deviance noted.
> 
> And yet, strangely, the world has been quite happy using C for half a 
> century while I have yet to hear anyone say your language looks great.

I haven't mentioned syntax at all. I've talked about type systems and 
array passing, and how, when I enumerated 3 kinds of parameter passing 
in my language, C's parameter passing most matched either number (1) or 
(3) of mine depending on parameter type. (3) was pass-by-reference.


>> It combines the A and N parameters commonly passed to functions, into 
>> a composite object. It is not entirely different!
>>
> 
> Yes, it is.
> 
> This thread would be so much simpler if you knew what you were talking 
> about, or at least accepted that other people do.

I have some doubts that /you/ do!

A slice would be a natural addition to C's arrays. Passing a slice 
passes a pointer to the array data, just like C does anyway (the slice 
is passed by value; the data by reference!).

Applied to char arrays, it gives you counted strings.