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

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).
While eliminating structs could also simplify things; structs also tend to be a lot more useful.
At least in BGBCC, internally types are represented as several logical fields:
   array size (usually 0 for non-arrays);
   (sometimes) a field holding an additional "modifier mode";
   pointer indirection level;
   ID number for primitive type or complex type/structure.
So, for part of the range, it is understood to represent one of the primitive types. Else it identifies a structure, which identifies the contents of a struct or function pointer or similar.
One can represent a multidimensional array by daisy-chaining the types (via a "typedef" entry whose sole purpose is to hold another type), but this is wonky. Though, C contains other occasionally used edge cases which require this.
Though, within the serialized IR stage, there is an ASCII notation, say:
   i             //int
   A4i           //int[4]
   A4,4i         //int[4][4]
   Pi            //int*
   PPi           //int**
   XSomeStruct;  //SomeStruct, given by name
   X123          //SomeStruct (given by index number)
   A4X123        //SomeStruct[4]
   P(xx)y        //unsigned long long (*)(long long, long long);
   ...
Where:
   a..z: Various primitive types.
   Cx, Gx: More primitive types.
Most capital letters represent structural features of the type.
Versus the compiler internally using a bit-packed format.
In the normal bit-packed form (with multiple sub-layouts existing), the various fields have a limited range. Going bigger turns into a case where the type is instead interpreted as an index into a table of "overflowed" types, which are represented as structures.
This is less desirable, as an entry in a table holding a dedicated struct is less desirable than a packed bit-pattern (but, logically, both can represent the same general information).

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.
 

The idea in this case was to make it so that:
   int[16];
Can be functionally identical to:
   int*
As far as most of the compiler's type-system handling is concerned. In this case, one only needs to care about the size when reserving space for the array.
One other simplification is also to make is so that:
   SomeStruct tfoo, tbar;
And:
   SomeStruct *pfoo, *pbar;
Are treated as equivalent at the lower levels, with the primary difference that:
   pbar=pfoo;
Will merely assign the pointer, whereas:
   tbar=tfoo;
Needs to reserve memory for the structs in the stack-frame or similar, and then effectively turns the assignment internally into:
   memcpy(&tbar, &tfoo, sizeof(SomeStruct));
The ABI in my case also typically passes (and returns) structs by reference (thus, at the low-level, the compiler and ABI can treat them as pointers). Though, struct return is a little wonky as one effectively passes in a hidden argument for where the structure is to be returned into (and trying to call a function that returns a struct by value with a missing prototype will very possibly result in a crash).
Though, functionally it is not that much different in this sense from either the Win64 x64 ABI, or the WinCE SH-4 ABI (from which part the core of my ABI design was derived). Though, can note that both the Win64 x64 and WinCE SH-4 ABI are "oddly similar" in many areas.
Granted, arrays of structs still represent some hassle, as one needs to multiply the index by the size of the struct when offsetting the pointer.
This is in strong contrast, say, to the RISC-V ABI, which directly copies the structure contents around in memory to pass and return them.
Well, and needs logic much more complex than:
   Does the struct fit into an integer type?
     Pass/return contents as the integer type.
   Else, pass/return as a pointer.
But, to preserve lvalue semantics, one may still need to pass structs by reference within a function (even if they are small enough to fit into an integer register).

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

Also kinda similar with C#.
But, I figured possibly going in a direction more like Java.
...