Thread overview
[OT] Dennis Ritchie's proposal for slices in C
Dec 09
user1234
Dec 09
user1234
December 08

As it turns out, even the original creator of C recognized its biggest mistake all the way back in 1990, and came up with a plan to address it. Here's the link to the paper:

https://www.bell-labs.com/usr/dmr/www/vararray.pdf

The syntax is a little weird--he uses

int (*arr)[?];

...instead of Walter's proposed

int arr[..];

...but the core idea is the same: "the pointers carry the array bounds inside themselves." That is, instead of a naked pointer, arr stores a pointer+length pair.

It's honestly kind of incredible that the C committee has been sitting on this for more than 30 years. What the heck were they thinking?

December 08
On 12/8/2024 2:48 PM, Paul Backus wrote:
> It's honestly kind of incredible that the C committee has been sitting on this for more than 30 years. What the heck were they thinking?

It is amazing indeed, considering all the useless complexity they've added to C, like normalized Unicode identifiers.

Of course, C++ refuses to fix it as well.

December 09

On Sunday, 8 December 2024 at 22:48:17 UTC, Paul Backus wrote:

>

As it turns out, even the original creator of C recognized its biggest mistake all the way back in 1990, and came up with a plan to address it. Here's the link to the paper:

https://www.bell-labs.com/usr/dmr/www/vararray.pdf

The syntax is a little weird--he uses

int (*arr)[?];

...instead of Walter's proposed

int arr[..];

...but the core idea is the same: "the pointers carry the array bounds inside themselves." That is, instead of a naked pointer, arr stores a pointer+length pair.

It's honestly kind of incredible that the C committee has been sitting on this for more than 30 years. What the heck were they thinking?

Yes, and this kind of makes the point WG14 has no interest fixing the issue, when not even one of the language authors can change their mind.

Note that the languages they designed afterwards, Alef, Limbo and Go, don't have this issue.

Also AT&T did had a go at other less well known languages like C+@ (yeah horrible idea as name, see [0]), and Cyclone (whose ideas ended up being known in mainstream via Rust).

[0] - https://encyclopedia2.thefreedictionary.com/C%2B%40

December 09

On Sunday, 8 December 2024 at 22:48:17 UTC, Paul Backus wrote:

>

It's honestly kind of incredible that the C committee has been sitting on this for more than 30 years. What the heck were they thinking?

Just a supposition but maybe that stdc was percepted as a blocker ?

As C has no overloads, no mangling, then supporting slices in stdc would have lead to an atrocious system of "wrap & dispatch" using-macros or IDK what else (prefixes or suffixes in the names of the variants accepting slices ?).

December 09

On Monday, 9 December 2024 at 10:22:19 UTC, Paulo Pinto wrote:

>

Yes, and this kind of makes the point WG14 has no interest fixing the issue, when not even one of the language authors can change their mind.

Note that the languages they designed afterwards, Alef, Limbo and Go, don't have this issue.

Alef was by Phil Winterbottom, not Richie. Richie probably had a hand in Limbo (since he wrote the reference manual), but likely not in Go.

While Alef did have a form of fat pointer (polymophic type / pointer), that seems to have been more akin to "interface{}" / aka "any" in Go, in that it carried type information, not bounds. I'm guessing that also got used when a Channel was able to carry one of a set of types (as opposed to chan of tuple-type).

As far as I can tell from the reference manual, Alef had identical array to pointer decomposition as in C.

December 09

On Sunday, 8 December 2024 at 22:48:17 UTC, Paul Backus wrote:

>

What the heck were they thinking?

It's a rhetorical question I see now. You're not supposed to answer to that.

December 09

On Sunday, 8 December 2024 at 23:39:34 UTC, Walter Bright wrote:

>

On 12/8/2024 2:48 PM, Paul Backus wrote:

>

It's honestly kind of incredible that the C committee has been sitting on this for more than 30 years. What the heck were they thinking?

It is amazing indeed, considering all the useless complexity they've added to C, like normalized Unicode identifiers.

Of course, C++ refuses to fix it as well.

+1

December 10

On Monday, 9 December 2024 at 14:29:08 UTC, Derek Fawcus wrote:

>

On Monday, 9 December 2024 at 10:22:19 UTC, Paulo Pinto wrote:

>

Yes, and this kind of makes the point WG14 has no interest fixing the issue, when not even one of the language authors can change their mind.

Note that the languages they designed afterwards, Alef, Limbo and Go, don't have this issue.

Alef was by Phil Winterbottom, not Richie. Richie probably had a hand in Limbo (since he wrote the reference manual), but likely not in Go.

While Alef did have a form of fat pointer (polymophic type / pointer), that seems to have been more akin to "interface{}" / aka "any" in Go, in that it carried type information, not bounds. I'm guessing that also got used when a Channel was able to carry one of a set of types (as opposed to chan of tuple-type).

As far as I can tell from the reference manual, Alef had identical array to pointer decomposition as in C.

Alef allowed for tuples, so for the short time it lived on Plan 9, it was possible to at least make use of tuples to easily pass pointer + length as a single unit around.

One can argue that this is also possible with structs, but for whatever psicological reason one is favoured over the other, although the purpose is kind of similar.

C and UNIX had two key designers, Ken Thompson is one of the three original contributors to Go, not Dennis.

Alongside Rob Pike, one of the key figures in Alef and Limbo design.