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

Type-Safe Unions in C++ and Rust

genbattle.bitbucket.org

Post reply on HN
Print view View original

91–100 of 140 posts

Re: Type-Safe Unions in C++ and Rust

#91

Post by [deleted] »

hellofunk wrote: post #57
bjz_ wrote: post #38

Earlier quoted context omitted.

Unfortunately that means they lack lots of the pattern matching niceties that you get in languages with builtin ADTs. There is an impressive paper about implementing pattern matching on sub-classes, but it's pretty hackily done using the preprocessor, and could definitely do with some language support: http://www.stroustrup.com/OpenPatternMatching.pdf

It is widely speculated that pattern matching and many other syntactic enhancements are coming to C++ because of the big door that std::variant has opened.

[deleted]

Re: Type-Safe Unions in C++ and Rust

#93

Post by jjnoakes »

pcwalton wrote: post #88
jjnoakes wrote: post #51

Is there any demand for a syntactic sugar layer on top of C++? Something to make these new features more ergonomic? Something one could opt-in to for newer code, or code that doesn't need to be backward compatible to 1990? Something that outputs valid C++ and so works with any tool chain?

That would be a compiler for a language to C/C++. That design decision is virtually always a bad idea: LLVM has simpler semantics, allows proper GC, allows proper debug info, is widely portable, and avoids a needless AST serialization/deserialization step. Don't compile to C.

Please don't tell others what not to do.

First, there are cases where compiling other languages to C or C++ is better than via LLVM; interoperability and portability are two (yes, C and C++ are more portable than LLVM).

Second, I'm not really talking about compiling some wildly different language to C++. I'm talking about some simple syntactic sugar. The same syntactic sugar that would be in an existing C or C++ compiler's front end, except instead of adding it to all the frontends in the world and waiting years, I'd like to implement it just once and now.

Re: Type-Safe Unions in C++ and Rust

#94

Post by Manishearth »

pcwalton wrote: post #89
Manishearth wrote: post #6

Earlier quoted context omitted.

One interesting thing about Rust is that none of the language features are really new . Even the borrow checker is from research papers and languages from quite a while ago. The only thing I can think of that might be truly unique to Rust is the concurrency safety model (Send+Sync), though that might be old too. Rust has just managed to take all these features and put them together well, and strive to be more than a…

> Even the borrow checker is from research papers and languages from quite a while ago. Eh, that's underselling Rust's contributions. Rust is more flexible than anything I know of when it comes to enforcing aliasing-xor-mutability. Cyclone for example was much more restrictive in disallowing aliasing (see Grossman's "Existential Types for Imperative Languages"). The key feature that Rust has is flow-sensitive permiss…

I guess, yeah. I meant that what Cyclone does is along the same lines.

> The key feature that Rust has is flow-sensitive permissions on unique loan paths, which is actually pretty novel as far as I'm aware.

Huh, right.

Re: Type-Safe Unions in C++ and Rust

#95

Post by nickpsecurity »

Jweb_Guru wrote: post #82
nickpsecurity wrote: post #75

Earlier quoted context omitted.

"which seems to be a concept only really formalised in the late 80s" http://brinch-hansen.net/papers/1975a.pdf http://brinch-hansen.net/papers/ His first, concurrent OS was RC 4000 in 1969. It had many mechanisms in place. He got the key parts of the safety problem figured out by 1972. His language to handle much of it statically at compile-time was done in 1975. His Boss 2 system same year used coroutines + similar…

This system does not support recursion. It also does not have to reason about atomics and so on because it is not intended for multicore systems; indeed, it assumes that all access is serialized through a mutex, and doesn't consider the existence of types like single-threaded reference counters (like Rust's Rc). It is describing threads with exclusive access, and a scheduling mechanism for waiting on locks, but the m…

"I agree that people have a strong tendency to not know what past work has been done, and Concurrent Pascal is admirable, but what Rust does is not the same thing. "

I'm not saying it does. The claim I replied to said preventing things like data races was done till well into the 80's. I showed systematic investigations of the problem plus a production solution had been done by mid-70's. You've nicely showed how far ahead methods like Rust got. ;)

Re: Type-Safe Unions in C++ and Rust

#96

Post by pcwalton »

jjnoakes wrote: post #93
pcwalton wrote: post #88

Earlier quoted context omitted.

That would be a compiler for a language to C/C++. That design decision is virtually always a bad idea: LLVM has simpler semantics, allows proper GC, allows proper debug info, is widely portable, and avoids a needless AST serialization/deserialization step. Don't compile to C.

Please don't tell others what not to do. First, there are cases where compiling other languages to C or C++ is better than via LLVM; interoperability and portability are two (yes, C and C++ are more portable than LLVM). Second, I'm not really talking about compiling some wildly different language to C++. I'm talking about some simple syntactic sugar. The same syntactic sugar that would be in an existing C or C++ comp…

Effort in this direction would be better spent just adding new features to clang (or GCC). It'll be so much easier than writing a new parser and semantic analysis for C++, which you will have to do if you want the new feature to behave properly in the presence of templates, etc. You'll end up wanting to just use clang's front end to help you, like most C++ tools do—and at that point why not just modify clang itself?

People bring up obscure platforms (though, interestingly, I can't recall anybody actually naming one of those platforms) all the time as motivation for compiling to C. But if you really need to do that, you can always revive the LLVM C backend. The fact that nobody has bothered to revive it and keep it up to date enough to be merged into LLVM proper, to me, is a strong indication that few people need support for these obscure platforms.

Re: Type-Safe Unions in C++ and Rust

#97

Post by pix64 »

jjnoakes wrote: post #51

Is there any demand for a syntactic sugar layer on top of C++? Something to make these new features more ergonomic? Something one could opt-in to for newer code, or code that doesn't need to be backward compatible to 1990? Something that outputs valid C++ and so works with any tool chain?

I think at that point you're creating a new language or at least a new (incompatible) version of the language. In this case, why limit yourself to C++ at all?

Re: Type-Safe Unions in C++ and Rust

#98

Post by nickpsecurity »

dbaupp wrote: post #80
nickpsecurity wrote: post #75

Earlier quoted context omitted.

"which seems to be a concept only really formalised in the late 80s" http://brinch-hansen.net/papers/1975a.pdf http://brinch-hansen.net/papers/ His first, concurrent OS was RC 4000 in 1969. It had many mechanisms in place. He got the key parts of the safety problem figured out by 1972. His language to handle much of it statically at compile-time was done in 1975. His Boss 2 system same year used coroutines + similar…

I don't have time to read it in full right now, but a quick glance over that paper doesn't show any formalisation of data races, which is specifically what that parenthetical is about, not just general "concurrency safety". Having a detailed description of concept seems important because Rust is fairly precise in what it defends against, possibly giving the programmer more flexibility and power than in a system that…

It's in the disk buffer and monitor examples. Here's a relevant quote:

"A disk buÆer is a data structure shared by two concurrent processes. The details of how such a buÆer is constructed are irrelevant to its users. All the processes need to know is that they can send and receive data through it. If they try to operate on the buÆer in any other way it is probably either a programming mistake or an example of tricky programming. In both cases, one would like a compiler to detect such misuse of a shared data structure."

"To make this possible, we must introduce a language construct that will enable a programmer to tell a compiler how a shared data structure can be used by processes. This kind of system component is called a monitor. A monitor can synchronize concurrent processes and transmit data between them. It can also control the order in which competing processes use shared, physical resources."

Sounds like he understands the problem is concurrent processes stepping on each others toes using a shared, data structure. He has nice drawings and charts to go with it. Plus, an early model to solve it statically at compile time. Jweb_Guru noted some limitations of his method but it understands and solves the fundamental problem. Hansen's own work improved on it later plus it was obsoleted by things like Ravenscar, SCOOP and now Rust's method. Nice that he had a whole OS protected from concurrency errors at compile time in the 70's, though. :)

Re: Type-Safe Unions in C++ and Rust

#99

Post by squidbidness »

hellofunk wrote: post #57
bjz_ wrote: post #38

Earlier quoted context omitted.

Unfortunately that means they lack lots of the pattern matching niceties that you get in languages with builtin ADTs. There is an impressive paper about implementing pattern matching on sub-classes, but it's pretty hackily done using the preprocessor, and could definitely do with some language support: http://www.stroustrup.com/OpenPatternMatching.pdf

It is widely speculated that pattern matching and many other syntactic enhancements are coming to C++ because of the big door that std::variant has opened.

IIRC Stroustrup mentions a desire for features such as these for versions of C++ after C++17.

Re: Type-Safe Unions in C++ and Rust

#100

Post by pjmlp »

Manishearth wrote: post #7
pjmlp wrote: post #5

Earlier quoted context omitted.

This seems to have become quite prevalent. Apparently the majority of CS degrees don't teach history of programming languages. On my language design lectures in the mid-90's we had to learn all major ones, all the way back to Fortran.

This really doesn't seem like a reinventing to me (from either the Rust or C++ side). "Reinventing" implies ignoring history in the way you mention. Tagged unions are prevalent in so many languages that the designers of both C++17 and Rust are bound to know about them. This is "borrowing" (or "stealing" :p). The original Rust was ML-like and had an OCaml compiler, so Rust's enums definitely descended from those. I ca…

I guess I was ranting a bit out of place....
Post reply on HN