Path: csiph.com!news.swapon.de!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Keith Thompson <Keith.S.Thompson+u@gmail.com>
Newsgroups: comp.lang.c
Subject: Re: technology discussion =?utf-8?Q?=E2=86=92?= does the world need a "new" C ?
Date: Fri, 05 Jul 2024 01:09:37 -0700
Organization: None to speak of
Lines: 66
Message-ID: <871q48w98e.fsf@nosuchdomain.example.com>
References: <v66eci$2qeee$1@dont-email.me> <v67gt1$2vq6a$2@dont-email.me> <v687h2$36i6p$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 05 Jul 2024 10:09:38 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="4654bd1604bef5db972e5af80bad421d"; logging-data="3373929"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+cKJY3vzbMx2MJQ5pC2QUj"
User-Agent: Gnus/5.13 (Gnus v5.13)
Cancel-Lock: sha1:8Sju8ZD5eVsU7aIVMPow+V/m8M4= sha1:imiaGGTck3yh3/CmVks1W+gysw0=
Xref: csiph.com comp.lang.c:386771

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.

I personally would hope that this language would *not* inherit C's
odd treatment of arrays and pointers.  If so, and if it supports
multidimensional arrays, they'd have to be defined differently than
the way they're defined in C.

(Ada, for example, has both arrays of arrays and multidimensional
arrays as distinct language features, using a(i)(j) to index the
former and a(i,j) to index the latter.)

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */