Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

GCC SC approves inclusion of Algol 68 Front End

gcc.gnu.org

Post reply on HN
Print view View original

81–90 of 115 posts

Re: GCC SC approves inclusion of Algol 68 Front End

#81

Post by LeFantome »

pjmlp wrote: post #27

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.

Re: GCC SC approves inclusion of Algol 68 Front End

#82

Post by seg_lol »

SkiFire13 wrote: post #51
FrankenApps wrote: post #38

Earlier quoted context omitted.

The Rust Community is working on gcc-rs for this very reason.

gcc-rs is far from being usable. If you want to use Rust with gcc-only targets you're probably better off with rustc_codegen_gcc instead.

One could also compile to wasm, and then convert that wasm to C.

Re: GCC SC approves inclusion of Algol 68 Front End

#83

Post by LeFantome »

adsl731898322 wrote: post #64

This is great news for GCC! I love how this decision supports older languages like Algol 68, keeping them alive in the FOSS world. It shows the hacker community's dedication to preserving diverse tools.

It is awesome.

That said, it really stands out to me that the two latest GCC languages are Cobol and Algol68 while LLVM gets Swift and Zig.

And Rust and Julia come from LLVM as well of course.

Re: GCC SC approves inclusion of Algol 68 Front End

#84

Post by fastaguy88 »

zozbot234 wrote: post #67
adrian_b wrote: post #43

Earlier quoted context omitted.

The "natural inverse" relationship between "address-of" and indirect addressing is only partial. You can apply the "*" operator as many times you want, but applying "address-of" twice is meaningless. Moreover, in complex expressions it is common to mix the indirection operator with array indexing and with structure member selection, and all these 3 postfix operators can appear an unlimited number of times in an expre…

A postfix "*" would be completely redundant since you can just use p[0] . Instead of *p++ you'd have (p++)[0] - still quite workable.

You're kidding, right? (p++)[0] returns the contents of (p) before the ++. Its hard to imagine a more confusing juxtaposition.

Re: GCC SC approves inclusion of Algol 68 Front End

#85

Post by comex »

LeFantome wrote: post #79
themafia wrote: post #49

Earlier quoted context omitted.

> You can apply the "*" operator as many times you want, but applying "address-of" twice is meaningless. This is due to the nature of lvalue and rvalue expressions. You can only get an object where * is meaningful twice if you've applied & meaningfully twice before. int a = 42; int *b = &a; int **c = &b; I've applied & twice. I merely had to negotiate with the language instead of the parser to do so. > and all these…

I do not think that is what they meant. **c is valid but &&b makes no sense.

Some languages do define &&b, like Rust, where its effect is similar to the parent post's C example: it creates a temporary stack allocation initialized with &b, and then takes the address of that.

You could argue this is inconsistent or confusing. It is certainly useful though.

Incidentally, C99 lets you do something similar with compound literal syntax; this is a valid expression:

    &(int *){&b}

Re: GCC SC approves inclusion of Algol 68 Front End

#87

Post by wahern »

syockit wrote: post #69
wahern wrote: post #10

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

Isn't that horribly out of date? More recent benchmarks elsewhere performed after some Go improvements show Go's C FFI having drastically lower overheard, by at least an order of magnitude, IIUC.

Re: GCC SC approves inclusion of Algol 68 Front End

#88

Post by somat »

dboreham wrote: post #26
somat wrote: post #24

Earlier quoted context omitted.

Yes, massively influential, but was it ever used or popular?, I always think of it as sort of the poster child for the danger of "design by committee". Sure it's ideas spawned many of today's languages, But wasn't that because at the time nobody could afford to actually implement the spec. So we ended up with a ton of "algols buts" (like algol but can actually be implemented and runs on real hardware).

Used extensively on Burroughs mainframes.

Wow, The Burroughs large system had special instructions explicitly for efficient algol use. You could almost say it was algol hardware. but algol 60 not 68.

https://en.wikipedia.org/wiki/Burroughs_Large_Systems

There is a large system emulator that runs in a browser, I did not get any algol written but I did have way to much fun going through the boot sequence.

https://www.phkimpel.us/B5500/webUI/B5500Console.html

Re: GCC SC approves inclusion of Algol 68 Front End

#89

Post by gnufx »

physicsguy wrote: post #50
0xpgm wrote: post #23

In my mind this highlights something I've been thinking about, the differences between FOSS influenced by corporate needs vs FOSS driven by the hacker community. FOSS driven by hackers is about increasing and maintaining support (old and new hardware, languages etc..) while FOSS influenced by corporate needs is about standardizing around 'blessed' platforms like is happening in Linux distributions with adoption of Ru…

I don’t know that that is fair. A number of years ago I worked on a POWER9 GPU cluster. This was quite painful - Python had started moving to use wheels and so most projects had started to build these automatically in CI pipelines but pretty much none of these even supported ARM let alone POWER9 architecture. So you were on your own for pretty much anything that wasn’t Numpy. The reason for this of course is just tha…

At least it's been fine for four years of research software on a POWER9 cluster I support (with nodes like the Summit system's).

Re: GCC SC approves inclusion of Algol 68 Front End

#90

Post by gnufx »

Not relevant to GCC, but one use for an old A68 compiler was apparently to be adapted for the old NA Software Fortran 90 compiler, I was told by a former colleague. I'd have expected Ada to be a closer fit, and I don't know how well the decision worked out.
Post reply on HN