Re: technology discussion → does the world need a "new" C ?

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.)

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!

--
Ben.