- Everything except C now has standard strings, not just arrays of characters. Almost all languages now have some standard way to do key/value sets. What else ought to be standard?
-- Arrays of more than one dimension would be helpful for numerical work. Most languages descended from C lack this. They only have arrays of arrays. Even Rust lacks it. Proposals run into bikeshedding - some people want rectangular slices out of arrays, which means carrying stride info around.
-- Standard types for 2, 3 and 4-element vectors would help in graphics work. There are too many different implementations of those in most language and too much conversion.
Things to think about:
- Rust's ownership restrictions are harsh. Can we keep the safety and do more?
-- The back-reference problem needs to be solved somehow. Back references can be done with Rc and Weak, but it's clunky.
-- Can what Rust does with Rc, RefCell, and .borrow() be checked at compile time? That allows eliminating the run-time check, and provides assurance that the run-time check won't fail. Something has to look at the entire call tree at compile time, and sometimes it won't be possible to verify this at compile time. But most of the time, it should be.
-- There's a scheme for ownership where there's one owning reference and N using references. The idea is to verify at compile time that the using references cannot outlive the owning one. Then there's no need for reference counds.
-- Can this be extended to the multi-thread case? There have been academic demos of static deadlock detection, but that doesn't seem to have made it into production languages.
-- A common idiom involves things being owned by handles, but also indexed for lookup by various keys. Dropping the handle drops the object and removes it from the indices. Is that a useful general purpose operation? It's one that gets botched rather often.
-- Should compilers have SAT-solver level proof systems built in?
-- Do programs really have to be in monospaced fonts? (Mesa on the Alto used the Bravo word processor as its text editor. Nobody does that any more.)
-- There's async, there are threads, and there are "green threads", such as Go's "goroutines". Where's that going?
-- Can we have programs which run partly in a CPU and partly in a GPU, compiled together with the appropriate consistency checks, so the data structures and calls must match to compile?
-- How about "big objects?" These are separately built program components which have internal state and some protection from their callers. Microsoft OLE did that, some .dll files do that, and Intel used to have rings of protection and call gates to help with that, hardware features nobody used. But languages never directly supported such objects.
> Do programs really have to be in monospaced fonts?
Of course not. I've been using a proportional font for at least 10 years and I'm still in business working on code bases shared with developers using monospaced fonts. Both work, none disturb the other, proportional is easier to read as any book can demonstrate. Alignment doesn't matter much.
How do you deal with writing code with multicursors when you have to type the same thing multiple times? With monospace I just ctrl+alt+down a couple times on aligned text and then type. With proportional fonts I don't suppose it's easy to align text exactly, so do you just not use multicursors or is there a solution you came up with that works?
I don't use multicursors much, not every year. I'm using emacs. I register a sequence of keys and apply it multiple times with control e, control e, control e etc.
I’ve been a professional programmer for 17 years and have never used multicursors. I don’t even fathom under what conditions you’d want to. I use Find and Replace.
Everyone programs a little differently. I often use it when e.g. using intrinsics and I want to change types. Find and replace isn't especially helpful when they're different names with substructure you need to modify locally.
> Everything except C now has standard strings, not just arrays of characters. Almost all languages now have some standard way to do key/value sets. What else ought to be standard?
I think that character strings should not be restricted to (or generally expected to be) Unicode (although using Unicode and other character sets will still be possible).
I also think that key/value lists should allow any or most types as keys, including references to objects. (PostScript allows any type to be used as keys except strings (they are converted to names if you use them as keys) and nulls.)
I think that big integers (which can have a program-specified limited length in programming languages with typed variables) and arrays of fixed-length records (which C already has; JavaScript has typed arrays which is a more limited implementation of this) are also things that would be helpful to include as standard.
> Arrays of more than one dimension would be helpful for numerical work.
I agree with this too; it is a good idea.
> Standard types for 2, 3 and 4-element vectors would help in graphics work.
This is probably helpful, too, although they can be used for stuff other than graphics work as well.
> Do programs really have to be in monospaced fonts?
No, but that is due to how it is displayed and is not normally a feature of the program itself. Many people including myself do use monospace fonts, but this should not usually be required.
> There's async, there are threads, and there are "green threads", such as Go's "goroutines". Where's that going?
I had read about "green threads" and I think that it is a good idea.
> How about "big objects?" These are separately built program components which have internal state and some protection from their callers. Microsoft OLE did that, some .dll files do that, and Intel used to have rings of protection and call gates to help with that, hardware features nobody used. But languages never directly supported such objects.
I also think it is sensible to have components that can be separated from the callers, and that operating system support (and perhaps hardware support) for such thing might be helpful. I would design a programming language for such an operating system that would directly support such objects.
Are C multidimensional arrays guaranteed to be contiguous in memory? In practice they are, but can one iterate through them just by incrementing a pointer which points to the first element without UB?
Yes, but is one allowed to move a pointer inside it as they see fit? On a one-dimensional array, one can iterate through it starting with a pointer pointing to the first element and ending with a pointer pointing one position past the last element (which the user is not allowed to dereference). For multidimensional arrays, the element type is an array too (with a smaller rank than the original one), so one could perform that type of iteration with a pointer to an array. My question is whether a pointer to the underlying scalar type can freely move inside the multidimensional array without UB, since it may have to actually leave the array it was originally part of. If that's not allowed, how could one build slices and other view types?
Yes, you can do that, it's fine as long as you stay within the bounds of the indexes. Under the hood, it's a single contiguous block of memory.
Although at least with 2d arrays I prefer to just use a 1d array and index it with [x * width + y], because one problem with multidimensional arrays in C is they need multiple allocations/frees.
Double indirection arrays with multiple allocations are 25 years obsolete (ok, there are some use cases) but since C99 we prefer to do it like the parent.
In your code link you over allocate memory, sizeof *arr is enough and you need to dereference like with (*arr)[i][j].
You need to dereference it because it is a pointer to an array, if you dereference you get an array. You can also let the first dimensions decay then it looks like:
Other than comptime, most of Zig ideas were already present in Modula-2, @ all over the place gives a "I miss Objective-C" flavour to it, and only source code ecosystem on a language supposed to be a systems programming language?
- Everything except C now has standard strings, not just arrays of characters. Almost all languages now have some standard way to do key/value sets. What else ought to be standard?
-- Arrays of more than one dimension would be helpful for numerical work. Most languages descended from C lack this. They only have arrays of arrays. Even Rust lacks it. Proposals run into bikeshedding - some people want rectangular slices out of arrays, which means carrying stride info around.
-- Standard types for 2, 3 and 4-element vectors would help in graphics work. There are too many different implementations of those in most language and too much conversion.
Things to think about:
- Rust's ownership restrictions are harsh. Can we keep the safety and do more?
-- The back-reference problem needs to be solved somehow. Back references can be done with Rc and Weak, but it's clunky.
-- Can what Rust does with Rc, RefCell, and .borrow() be checked at compile time? That allows eliminating the run-time check, and provides assurance that the run-time check won't fail. Something has to look at the entire call tree at compile time, and sometimes it won't be possible to verify this at compile time. But most of the time, it should be.
-- There's a scheme for ownership where there's one owning reference and N using references. The idea is to verify at compile time that the using references cannot outlive the owning one. Then there's no need for reference counds.
-- Can this be extended to the multi-thread case? There have been academic demos of static deadlock detection, but that doesn't seem to have made it into production languages.
-- A common idiom involves things being owned by handles, but also indexed for lookup by various keys. Dropping the handle drops the object and removes it from the indices. Is that a useful general purpose operation? It's one that gets botched rather often.
-- Should compilers have SAT-solver level proof systems built in?
-- Do programs really have to be in monospaced fonts? (Mesa on the Alto used the Bravo word processor as its text editor. Nobody does that any more.)
-- There's async, there are threads, and there are "green threads", such as Go's "goroutines". Where's that going?
-- Can we have programs which run partly in a CPU and partly in a GPU, compiled together with the appropriate consistency checks, so the data structures and calls must match to compile?
-- How about "big objects?" These are separately built program components which have internal state and some protection from their callers. Microsoft OLE did that, some .dll files do that, and Intel used to have rings of protection and call gates to help with that, hardware features nobody used. But languages never directly supported such objects.
So there are a few simple ideas to think about.