News for hackers. Stuff that matters.
Re:Perl and Undecidability (2008) by c0m0 on Monday November 20, 2017 @06:23AM (#15739186)
Actually the problem has more implications, as it's an effect of parsing the code. Any IDE:s that have advanced features that rely on parsing and analysis of the code can be caught in an infinite loop and stop responding.

The sad part is, in the general case it's impossible for the parser (or any other process overviewing it) to decide if it's actually caught in an infinite loop or not, that's why they call it undecidability.

Re:Perl and Undecidability (2008) by eru on Monday November 20, 2017 @07:42AM (#15739484)
In theory, yes. Of course in practice, it's not so bad: they can run the parser in a different thread, they can put hard limits on how long they run, etc.

(The hard limit is how C++ gets parsed, I think. Since parsing C++ is also undecidable thanks to weird interactions with template metaprogramming.)

Re:Perl and Undecidability (2008) by knome on Monday November 20, 2017 @08:25AM (#15739694)
Yes, templates are turing complete.

https://github.com/knome/metabrainfuck/blob/master/bf.cpp

Does attempting to autocomplete such a template cause issues for IDEs? I used emacs when writing it, so I've never tested such a thing.

Re:Perl and Undecidability (2008) by eru on Monday November 20, 2017 @09:15AM (#15739961)
For simpler languages you can implement logic in the editor / IDE for things like precise autocomplete and parsing.

For C++ even precise syntax colouring would be undecidable---and just hard to get the logic right. There are two ways out: (1) implement an approximation and the occasional impression, (2) ask the compiler for help. I think the llvm project helps with the latter.

(What does emacs have to do with things? Or do you mean you are using emacs without any special support for C++? With the right modes you can turn your emacs (or vim etc) into basically a fully fledged IDE.)