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

Parsing C++ is literally undecidable (2013)

blog.reverberate.org

Post reply on HN
Print view View original

31–40 of 146 posts

Re: Parsing C++ is literally undecidable (2013)

#31

Post by rienbdj »

skocznymroczny wrote: post #13
rienbdj wrote: post #10

Can we design a language (cpp-prime?) that is basically c++ but makes parsing easier? I'm thinking reduce the keyword reuse, use different symbols for multiplication and pointers etc. The code would be easy for c++ developers to read and converting between the two could be automatic. However, we would be able to build tooling for this new language much more easily. It would also compile quicker.

In theory that's D. D was designed to be easier to parse than C++, for example, it uses Foo!Bar and Foo!(Bar, 4) template syntax rather than Foo and Foo . On the other hand, it still uses templates and supports mixins (basically #define on steroids), so while it's easy to parse, large chunks of code don't exist until compile time so can't be indexed by IDEs perfectly.

Not quite, because D brings many other things. I mean something that is equivalent to C++, with all of the same semantics, but a less ambiguous grammar.

Re: Parsing C++ is literally undecidable (2013)

#32

Post by jokoon »

xiphias2 wrote: post #25
rienbdj wrote: post #10

Can we design a language (cpp-prime?) that is basically c++ but makes parsing easier? I'm thinking reduce the keyword reuse, use different symbols for multiplication and pointers etc. The code would be easy for c++ developers to read and converting between the two could be automatic. However, we would be able to build tooling for this new language much more easily. It would also compile quicker.

Rust seems to be the most successful zero-overhead language competitor to C++, though it's far not as mature as C++ yet.

Rust has a high learning curve (borrowing, etc). Rust is a competitor to ADA, not C++. You can certainly ask developers to write things in rust instead, and even progressively rewrite codebase in rust since it's compatible with C++, but a language is about adopters, and ease of learning for beginners and students.

Re: Parsing C++ is literally undecidable (2013)

#33

Post by pjmlp »

jstimpfle wrote: post #28
pjmlp wrote: post #24

Earlier quoted context omitted.

Plenty of GC enabled system languages have proven their value, up to building full stack graphical workstations, so far they just lacked somg big corp political and monetary willingness to push them down the anti-GC devs no matter what. Thanfully with the likes of Swift on iDevices, Java/Kotlin on Android (with an increasingly constrained NDK), COM/UWP über alles + .NET on Windows, ChromeOS + gVisor, Unreal + GCed C+…

> I give it about 10 years time, for pure manual memory management to be like Assembly and embedded development. For someone who has spent some time thinking about memory management strategies, manual MM isn't actually that much additional work. By far, most code doesn't allocate or free (and that's a good thing). So MM->GC is hardly like Assembly->Compiler. In Assembly you're constantly allocating and pigeonholing,…

On single developer projects as long as one doesn't stay too much away from them, scale it up to multiple sized distributed teams, add binary libraries, and you end up with double frees, leaks and ownership issues all over the place.

Re: Parsing C++ is literally undecidable (2013)

#34

Post by gpderetta »

choeger wrote: post #22

This is one of the major issues with these languages that were initially designed by amateurs (I mean that in the positive sense, someone who does something because they care about it, and not because they are paid to do it). Often they simply did not see the long-term benefit of adhering to the limits of a "standard" architecture (i.e., context-free, unambiguous grammar, decidable static analysis (lookup!), multi-pa…

>Yet these hackers still made a successful product.

Worse is, was and always will be better. It seems that's an unchanging law of software design. Practicality, getting things done and catering to user needs always beats purity, elegance and soundness.

Re: Parsing C++ is literally undecidable (2013)

#35

Post by gpderetta »

msla wrote: post #3
lallysingh wrote: post #2

This is why the tools situation in c++ had been so far behind other languages like Java. You have to build a full frontend to even parse the language. They're slowly becoming available via clang now, which is nice.

I wonder if it's possible to craft a non-gigantic C++ file which causes a clang frontend to crash.

ICEs [1] used to be very common from all front ends especially with malformed template code, but now a day I think most compilers don't report an ICE to the user as long as they managed to issue at least one diagnostic.

It is still not uncommon to se ICEs on some extreme template constructs.

[1] Internal Compiler Error, i.e. the compiler segfaulted or hit an internal assertion.

Re: Parsing C++ is literally undecidable (2013)

#36

Post by gpderetta »

rienbdj wrote: post #10

Can we design a language (cpp-prime?) that is basically c++ but makes parsing easier? I'm thinking reduce the keyword reuse, use different symbols for multiplication and pointers etc. The code would be easy for c++ developers to read and converting between the two could be automatic. However, we would be able to build tooling for this new language much more easily. It would also compile quicker.

You could, but the incompatibility is not necessarily worth it.

There was some talk to take advantage of the transition to modules to be able to mark translation units as implementing a specific version of the standard (I think rust doese something similar) to allow for backward incompatibile Evolution of the language.

The committee doesn't seem to keen because they fear the language fragmenting and from a more practical point of views we will be still #including legacy code into new modules for at leas a decade (and I'm probably wildly optimistic).

Re: Parsing C++ is literally undecidable (2013)

#37

Post by jacobush »

pjmlp wrote: post #24
otabdeveloper4 wrote: post #20

Earlier quoted context omitted.

> due to their lack of manpower vs other languages offerings and continuous improvements No. D failed due to a mandatory GC and the 'two standard libraries' idiocy.

Plenty of GC enabled system languages have proven their value, up to building full stack graphical workstations, so far they just lacked somg big corp political and monetary willingness to push them down the anti-GC devs no matter what. Thanfully with the likes of Swift on iDevices, Java/Kotlin on Android (with an increasingly constrained NDK), COM/UWP über alles + .NET on Windows, ChromeOS + gVisor, Unreal + GCed C+…

Plenty did but none took a chunk out the C++ world that thrives on manual memory mgmt.

Re: Parsing C++ is literally undecidable (2013)

#38

Post by gpderetta »

pjmlp wrote: post #33
jstimpfle wrote: post #28

Earlier quoted context omitted.

> I give it about 10 years time, for pure manual memory management to be like Assembly and embedded development. For someone who has spent some time thinking about memory management strategies, manual MM isn't actually that much additional work. By far, most code doesn't allocate or free (and that's a good thing). So MM->GC is hardly like Assembly->Compiler. In Assembly you're constantly allocating and pigeonholing,…

On single developer projects as long as one doesn't stay too much away from them, scale it up to multiple sized distributed teams, add binary libraries, and you end up with double frees, leaks and ownership issues all over the place.

Purely anecdotally, I spend very little of my time thinking about what passes for manual memory management in C++.

For me the big attraction of GC is memory safety not convenience.

Re: Parsing C++ is literally undecidable (2013)

#39

Post by smitty1e »

rightbyte wrote: post #26
choeger wrote: post #22

This is one of the major issues with these languages that were initially designed by amateurs (I mean that in the positive sense, someone who does something because they care about it, and not because they are paid to do it). Often they simply did not see the long-term benefit of adhering to the limits of a "standard" architecture (i.e., context-free, unambiguous grammar, decidable static analysis (lookup!), multi-pa…

If I remember correctly Stroustrup was working at Bell labs in the initial phases of the cpp design with a formal education in CS. Hardly an amateur? Inexperienced maybe.

For a random sampling of the internet, being a critic of a complex system is trivial.

Offering an alternative that's an objective improvement, much less, on par with the status quo?

Not so much.

Re: Parsing C++ is literally undecidable (2013)

#40

Post by vkazanov »

rightbyte wrote: post #26
choeger wrote: post #22

This is one of the major issues with these languages that were initially designed by amateurs (I mean that in the positive sense, someone who does something because they care about it, and not because they are paid to do it). Often they simply did not see the long-term benefit of adhering to the limits of a "standard" architecture (i.e., context-free, unambiguous grammar, decidable static analysis (lookup!), multi-pa…

If I remember correctly Stroustrup was working at Bell labs in the initial phases of the cpp design with a formal education in CS. Hardly an amateur? Inexperienced maybe.

"Formal education in CS" is not the same as, say, a degree related to programming languages or compilers.
Post reply on HN