Path: ...!3.eu.feeder.erje.net!feeder.erje.net!weretis.net!feeder8.news.weretis.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: BGB <cr88192@gmail.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: Fri, 5 Jul 2024 22:30:53 -0500
Organization: A noiseless patient Spider
Lines: 232
Message-ID: <v6adrm$3ljg6$1@dont-email.me>
References: <v66eci$2qeee$1@dont-email.me> <v67gt1$2vq6a$2@dont-email.me>
 <v687h2$36i6p$1@dont-email.me> <871q48w98e.fsf@nosuchdomain.example.com>
 <v68dsm$37sg2$1@dont-email.me> <87plrsultu.fsf@bsb.me.uk>
 <v68sft$3a6lh$1@dont-email.me> <87ed87v4wi.fsf@bsb.me.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sat, 06 Jul 2024 05:32:07 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="d3c5ef1cde4e45ddc2826fbe07375cf5";
	logging-data="3853830"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+mbF5Yle1jmXMdY6PrNhy7I5VIAu50IsI="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:mu++plB+H7kLrZ71No7cN9vX8ww=
Content-Language: en-US
In-Reply-To: <87ed87v4wi.fsf@bsb.me.uk>
Bytes: 10091

On 7/5/2024 5:40 PM, Ben Bacarisse wrote:
> BGB <cr88192@gmail.com> writes:
> 
>> On 7/5/2024 6:20 AM, Ben Bacarisse wrote:
>>> BGB <cr88192@gmail.com> writes:
>>>
>>>> On 7/5/2024 3:09 AM, Keith Thompson wrote:
>>>>> BGB <cr88192@gmail.com> writes:
>>>>>> On 7/4/2024 8:05 PM, Lawrence D'Oliveiro wrote:
>>>>>>> It’s called “Rust”.
>>>>>>
>>>>>>
>>>>>> If anything, I suspect may make sense to go a different direction:
>>>>>>      Not to a bigger language, but to a more narrowly defined language.
>>>>>>
>>>>>> Basically, to try to distill what C does well, keeping its core
>>>>>> essence intact.
>>>>>>
>>>>>>
>>>>>> Goal would be to make it easier to get more consistent behavior across
>>>>>> implementations, and also to make it simpler to implement (vs an
>>>>>> actual C compiler); with a sub-goal to allow for implementing a
>>>>>> compiler within a small memory footprint (as would be possible for K&R
>>>>>> or C89).
>>>>>>
>>>>>>
>>>>>> Say for example:
>>>>>>      Integer type sizes are defined;
>>>>>>      Nominally, integers are:
>>>>>>        Twos complement;
>>>>>>        Little endian;
>>>>>>        Wrap on overflow.
>>>>>>      Dropped features:
>>>>>>        VLAs
>>>>>>        Multidimensional arrays (*1)
>>>>>>        Bitfields
>>>>>>        ...
>>>>>>      Simplified declaration syntax (*2):
>>>>>>        {Modifier|Attribute}* TypeName Declarator
>>>>>>
>>>>>>
>>>>>> *1: While not exactly that rare, and can be useful, it is debatable if
>>>>>>     they add enough to really justify their complexity and relative
>>>>>>     semantic fragility. If using pointers, one almost invariably needs to
>>>>>>     fall back to doing "arr[y*N+x]" or similar anyways, so it is arguable
>>>>>>     that it could make sense to drop them and have people always do their
>>>>>>     multidimensional indexing manually.
>>>>>>
>>>>>> Note that multidimensional indexing via multiple levels of pointer
>>>>>> indirection would not be effected by this.
>>>>> [...]
>>>>> Multidimensional arrays in C are not a distinct language feature.
>>>>> They are simply arrays of arrays, and all operations on them follow
>>>>> from operations on ordinary arrays and pointers.
>>>>> Are you proposing (in this hypothetical new language) to add
>>>>> an arbitrary restriction, so that arrays can have elements of
>>>>> arithmetic, pointer, struct, etc. type, but not of array type?
>>>>> I'm not sure I see the point.
>>>>
>>>> As-is, the multidimensional arrays require the compiler to realize that it
>>>> needs to multiply one index by the product of all following indices.
>>>>
>>>> So, say:
>>>>     int a[4][4];
>>>>      int j, k, l;
>>>>      l=a[j][k];
>>>>
>>>> Essentially needs to be internally translated to, say:
>>>>      l=a[j*4+k];
>>>>
>>>> Eliminating multidimensional arrays eliminates the need for this
>>>> translation logic, and the need to be able to represent this case in the
>>>> typesystem handling logic (which is, as I see it, in some ways very
>>>> different from what one needs for a struct).
>>> How can it be eliminated?  All your plan does is force me to wrap the
>>> inner array in a struct in order to get anything like the convenience of
>>> the above:
>>> struct a { int a[4]; };
>>> struct a a[4];
>>> l = a[j].a[k];
>>> Most compilers with generate the same arithmetic (indeed exactly the
>>> same code) for this as for the more convenient from that you don't like.
>>> All you can do to eliminate this code generation is to make it so hard
>>> to re-write the convenient code you dislike.  (And yes, I used the same
>>> name all over the place because you are forcing me to.)
>>>
>>
>> It is not so much a dislike of multidimensional arrays as a concept, but
>> rather, the hair they add to the compiler and typesystem.
>>
>> Granted, one would still have other complex types, like structs and
>> function pointers, so potentially the complexity savings would be
>> limited.
> 
> Then the "hair" is still there.
> 

Possibly true.

I am now left thinking maybe the issue was not that the multidimensional 
arrays exist, but rather, how I had approached implementing them...


Ironically, I probably should have leaned harder into the "daisy chained 
types" interpretation, rather than treating it as an undesirable 
implementation tradeoff.


As noted, my conceptual approach to types was a little different; and, 
implicitly, more directly mimics how types behave in the Java VM (but 
with C like type semantics being expressed on top of this).


Though, rather than I/L/F/D/A (Int/Long/Float/Double/Address) as the 
fundamental types, it is more like I/L/D/X/A/V 
(Int/Long/Double/XLong/Address/Variant).

With arrays and by-value structs being treated like subtypes of the 
Address type, just with pre reserved storage being created in the prolog.

Variant also exists, holding any types that are nominally represented as 
tagged references (and type-checked at runtime; though using all this is 
non-standard in C).

The XLong category mostly holds types with a 128-bit format.


Well, and with a C compiler that originally started out as an 
interpreter for a JavaScript clone (before later taking influence from 
the JVM and moving towards a static-typed core; with a fork of this VM 
having been modified to be able to parse C, ...).

Design isn't entirely free from hair.


The backend did end up with a fair bit of complexity as well, as some 
initial ideas turned out to not have been so good in retrospect.


>>>> While eliminating structs could also simplify things; structs also tend to
>>>> be a lot more useful.
>>> Indeed.  And I'd have to use them for this!
>>>
>>
>> Errm, the strategy I would assume is, as noted:
>>    int a[4][4];
>>    ...
>>    l=a[j][k];
>> Becomes:
>>    int a[16];
>>    ...
>>    l=a[j*4+k];
> 
> That's what you want to force me to write, but I can use and array of
> arrays despite your arbitrary ban on them by simply putting the array in
> a struct.
> 
> Anyway, sine C exists, I won't be forced to use your proposed
> alternative.
> 

IN most contexts, I don't really see how a struct is preferable to a 
multiply, but either way...


Whole language design is still a hypothetical at this point anyways (and 
my actual compiler does support multidimensional arrays).


>> Much like what one would typically need to do anyways if the array was
>> heap-allocated.
> 
> Only if you forbid variably modified types (note not VLAs).
> 
>    int (*a)[n] = malloc(m * sizeof *a);
========== REMAINDER OF ARTICLE TRUNCATED ==========