101–110 of 115 posts
Earlier quoted context omitted.
I wonder about what you think is wrong with C? C is essentially a much simplified subset of ALGOL68. So what is missing in C?
Proper strings and arrays for starters, instead of being pointers that the programmer is responsible for doing length housekeeping.
Earlier quoted context omitted.
The issue is that certain specific parts of the industry currently pour in a lot of money into the Rust ecosystem, but selectively only where they need it.
How is that different than scratching one’s own itch?
Earlier quoted context omitted.
https://rosettacode.org/wiki/Category:ALGOL_68 https://github.com/search?q=algol68&type=repositories Without knowing what your interests/motivations and backgrounds are, it is hard to make good recommendations, but if you didn't know about rosettacode or github I figured I should start with that
What I'm taking away from this is that there's absolutely zero code of interest that is Algol 68
Just because you can’t find something interesting doesn’t mean it isn’t interesting.
That lesson once learned pays dividends
Earlier quoted context omitted.
Until a few years ago, gccgo was well maintained and trailed the main Go compiler by 1 or 2 releases, depending on how the release schedules aligned. Having a second compiler was considered an important feature. Currently, the latest supported Go version is 1.18, but without Generics support. I don't know if it's a coincidence, but porting Generics to gccgo may have been a hurdle that broke the cadence.
The best thing about gccgo is that it is not burdened with the weirdness of golang's calling convention, so the FFI overhead is basically the same as calling an extern function from C/C++. Take a look at [0] and see how bad golang's cgo calling latency compare to C. gccgo is not listed there but from my own testing it's the same as C/C++. [0]: https://github.com/dyu/ffi-overhead
Interesting. I saw go breaking from the c abi as the primary reason to use it; otherwise you might as well use java or rust.
Earlier quoted context omitted.
Proper strings and arrays for starters, instead of being pointers that the programmer is responsible for doing length housekeeping.
Arrays are not pointers and if you do not let them decay to one, they do preserve the length information.
Kind of hard when passing them around as funcion parameters, and the static trick doesn't really work in a portable way.
Lets seen how far WG14 gets with cybersecurity laws with this kind of answers being analysed by SecDevOps and Infosec experts.
I find this great, finally an easy way to play with ALGOL 68, beyond the few systems that made use of it, like the UK Navy project at the time. Ironically, Algol 68 and Modula-2 are getting more contributions than Go, on GCC frontends, which seems stuck in version 1.18, in a situation similar to gcj. Either way, today is for Algol's celebration.
This makes me worry for the GCC implementation of Rust. People do not seem to use or upkeep the GCC versions of languages who primary Open Source implementations are elsewhere.
Regarding Go, gccgo was a way to have a better compiler backend for those that care about optimizations that reference Go compiler isn't capable of, due to the difference in history, philosophy, whatever.
Apparently that effort isn't seen as worthwile by the community.
Earlier quoted context omitted.
I think what C is missing is everything that people fall back onto clever use of pointers and macros to implement. Not that I think C should have all those things, Zig does a decent job of showing alternatives.
Yeah, but I meant specifically from ALGOL68.
Earlier quoted context omitted.
That test is short enough to just paste it in here: begin real procedure A(k, x1, x2, x3, x4, x5); value k; integer k; real x1, x2, x3, x4, x5; begin real procedure B; begin k := k - 1; B := A := A(k, B, x1, x2, x3, x4) end; if k ≤ 0 then A := x4 + x5 else B end; outreal(1, A(10, 1, -1, -1, 1, 0)) end The whole "return by assigning to the function name" is one of my least favorite features of Pascal, which I suppose…
Yeah that's one of the things the test was designed to catch: at that point, B is a reference , to the B that is being defined. Here's a C++ translation from https://oeis.org/A132343 that uses identity functions to make the types consistent: #include #include using cf = std::function ; int A(int k, cf x1, cf x2, cf x3, cf x4, cf x5) { int Aval; cf B = [&]() { int Bval; --k; Bval = Aval = A(k, B, x1, x2, x3, x4); retu…
Earlier quoted context omitted.
Arrays are not pointers and if you do not let them decay to one, they do preserve the length information.
They surely behave like one as soon as they leave local scope. Kind of hard when passing them around as funcion parameters, and the static trick doesn't really work in a portable way. Lets seen how far WG14 gets with cybersecurity laws with this kind of answers being analysed by SecDevOps and Infosec experts.
void arr_fn(char (*arr)[15]) {
enum { len = sizeof *arr }; printf("len of array: %d\n", len);
printf("Got: %.*s\n", len, *arr);
}
void sptr_fn(char ptr[static 15]) { printf("Got: %s\n", ptr); }
int main(void) {
char array[15] = "Hello, World!";
arr_fn(&array); sptr_fn(array); return 0;
}
One can hide that ptr to array behind a typedef to make it more readable:
typedef char (Arr_15)[15];
void arr_fn2(Arr_15 *arr) {
Earlier quoted context omitted.
They surely behave like one as soon as they leave local scope. Kind of hard when passing them around as funcion parameters, and the static trick doesn't really work in a portable way. Lets seen how far WG14 gets with cybersecurity laws with this kind of answers being analysed by SecDevOps and Infosec experts.
Then don't allow it to decay: void arr_fn(char (*arr)[15]) { enum { len = sizeof *arr }; printf("len of array: %d\n", len); printf("Got: %.*s\n", len, *arr); } void sptr_fn(char ptr[static 15]) { printf("Got: %s\n", ptr); } int main(void) { char array[15] = "Hello, World!"; arr_fn(&array); sptr_fn(array); return 0; } Using gcc (and similarly clang) removing the '15' from 'array', and allowing it to allocate it as 14…
The issues as it stands today are:
- It is still a warning instead of an error, and we all know how many projects have endless lists of warnings
- Only GCC and clang issue such warning, if we want to improve C, security must be imposed to all implementations