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

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);
 allows me to index a[i][j] conveniently.
 

This is another one of the edge cases that I would likely omit from such a language (rarely used in my experience).
But, as noted elsewhere, sizeof would also likely no longer be allowed for expressions.

Though, the major goal for this sort of thing is mostly to try to limit the
complexity required to write a compiler (as opposed to programmer
convenience).

 Ah.
 

Like, for example, I had tried (but failed) to write a usable C compiler in
less than 30k lines (and also ideally needing less than 4MB of RAM). But,
if the language design is simplified some, this might be a little
closer. Might still be doable, but a C compiler in 50-75k lines is much
less impressive.

 Why do you think this matters to other people?
 

As-is, C compilers tend to be a relative pain to implement.
A simplified language would be less of a pain, so people can more easily throw together their own compiler as-needed, rather than have an implicit assumption of "one compiler to rule them all".
But, C is at least a little more amendable to people rolling their own compilers, than, say, a language like C++ (where hand-rolling a full-featured C++ compiler seems likely out of reach for a single developer project).
But, say, for example, you want to be able to write a compiler that runs on a system with relatively limited RAM and possibly no MMU.
Granted, there is also MicroPython, but... blarg...
At present, I was left with inertia from my current compiler:
Given I am pretty much exclusively cross-compiling from a PC, the incentive to invest effort on a smaller compiler is lacking.
Technically, I might also want a compiler that can deal with GLSL.
Using my existing compiler to static compile shader programs would be possible, but tacky and wouldn't mesh well with the OpenGL API (which generally expects shaders to be loaded in plain text form, rather than, say, as a statically-compiled part of the program, or as COFF objects or DLLs or similar).