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

51–60 of 146 posts

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

#51

Post by gmueckl »

otabdeveloper4 wrote: post #20
pjmlp wrote: post #19

Earlier quoted context omitted.

And as much as I like their community, I feel it already lost its spotlight opportunity, due to their lack of manpower vs other languages offerings and continuous improvements. Even if C++ is a little baroque, C++17 and now C++20 provide many of the D's benefits, while keeping all the libraries, and finally we are getting Java like C++'s tooling to just throw it away.

> 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.

The GC is realistically only an issue in rare fringe cases. Early on, the competing standard libraries were a massive problem, though. This was overcome with D2, which is already more than a decade old.

When this standard library competition existed, the library ecosystem had this very weird split where half of the libraries you would have liked to use in your project used the other library you couldn't link to at the same time. This prevented me from picking up and trying D for a long time because I didn't want to deal with that. Now that this is over with and a ton of useful libraries exist, I'm glad that I started to use D because this is now a language in which I'm very productive.

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

#52

Post by coldtea »

iainmerrick wrote: post #50
vkazanov wrote: post #40

Earlier quoted context omitted.

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

Sure it is! A reputable CS degree will cover multiple programming languages and compiler implementation. I don’t think you could study just “compilers”, say, at undergrad level. Maybe you mean postgrad or postdoc-level qualifications? It would certainly be a pretty different world if you were only allowed to design a new programming language after getting your PhD in language design.

>Sure it is! A reputable CS degree will cover multiple programming languages and compiler implementation.

Which is neither here, nor there. A reputable CS degree is an all rounder, it's not expertise in PL design and research.

>I don’t think you could study just “compilers”, say, at undergrad level. Maybe you mean postgrad or postdoc-level qualifications?

For starters, yes, but it's not about official qualifications. Someone (e.g. Simon Peyton Jones) could be a PL expert without "official qualification" in the form of such a degree.

Even writing many increasingly successful languages could do it. Starting with your first (or first serious) attempt at a language, however, is not that...

Anders Hejlsberg is another famous example. He didn't complete his university (and it was on Engineering anyway), but after decades of successful work on the field be became a major PL designer and expert.

Stroustrup, however, was hardly anything like that at the time he first designed C++.

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

#53

Post by tempguy9999 »

tralarpa wrote: post #48
vkazanov wrote: post #40

Earlier quoted context omitted.

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

Yes. There is a section in one of his books where he wrote that he added some feature in an ad-hoc way just because of a request from a colleague. Unfortunately, as I have already written in another comment some months ago, C++ was the wrong thing that came at the right time (C people were starting looking for alternatives, seeing what cool things other languages were doing).

I think you might mean the 'protected' thing in classes. It was something he regretted later.

IIRC the person who asked for it also regretted that, but I'm less sure on that.

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

#54

Post by amelius »

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…

> 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).

As opposed to a "professional" who is told by their boss to implement X before the end of the day?

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

#55

Post by pjmlp »

jacobush wrote: post #37
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+…

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

The C++ world that thrives on manual memory management is usually "C compiled with C++ compilers".

The rest of the C++ world has long moved into automatic memory management as best practices.

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

#56

Post by username90 »

millstone wrote: post #7
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.

Java has generics and overloading; how far can you realistically get before building a full frontend? Honest question.

Java generics are just syntactic sugar for Object, so not a problem at all since you can't do anything with them.

Java overloading is simple since all functions are in the same file (so doesn't change overload behavior depending on which files are imported) and Java lacks the user type casts C++ has, so just pick the signature fitting all provided values (with numeric casts) or throw.

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

#58

Post by cmrdporcupine »

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.

Oh, you haven't read this classic paper?

http://users.monash.edu/~damian/papers/PDF/ModestProposal.pd...

"We describe an alternative syntactic binding for C++. This new binding includes a completely redesigned declaration/definition syntaxfor types, functions and objects, a simplified template syntax, and changes to several problematic operators and control structures. Theresulting syntax is LALR(1) parsable and provides better consistency in the specification of similar constructs, better syntacticdifferentiation of dissimilar constructs, and greater overall readability of code."

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

#59

Post by etalian »

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.

I wondered the same a while ago, and it turns out you can, in fact to test this hypothesis I ended up implementing such a language myself. The resulting syntax can express every construct from modern C++, is fully LALR(1) (no ambiguities and no vexing parses), has fewer keywords and is in general shorter than the equivalent C++ code, and once you know the syntax it is (subjectively) easier to read too (no spiral rule for example). Plus of course it can fully interoperate with existing C++.

Have been waiting to make it open source until I have finished writing the user manual (aiming for the end of this year), if that's interesting to you I post updates about it on twitter at cigmalang.

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

#60

Post by bitwize »

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+…

Building a GC into your system means building nondeterministic amounts of latency into it. Those "full stack graphical workstations" were notorious for being slow, expensive, and coming to a dead halt whenever the heap filled up.

Thankfully, we have RAII as in C++ and Rust and ARC in Swift, which give you automatic memory management without a tracing GC.

If your language requires a GC, it is a complete failure as a systems programming language.

Post reply on HN