Complexity of IDE error detection and auto-completion dependent upon language syntax?
Asked Answered
S

1

6

Are fewer checks/less rigorous code analysis required to provide development environment error feedback and auto completion for programming languages that are composed largely of human-readable phrases and words (i.e. Python, VB.NET)? This is in contrast to C-style languages, that depend more upon symbols and punctuation for code structure.

Scutcheon answered 22/5, 2012 at 13:7 Comment(7)
Before defining "easier," which you avoided, please define "verbose" and "terse."Fructify
@Close Voters: This question is not about whether VB is better thatn C#.Kinsfolk
My guess would be, it's not about verbosity; rather, it's about the fact that more things are allowed in C#, and therefore the parser has more ways of interpreting a line of code.Kinsfolk
"More things are allowed"? These days, the only real difference between the two is syntax.Vanguard
@Kinsfolk is right..I'm not C# basing, in fact I prefer it. I'll update my definitions per Jason's request.Scutcheon
The hardest part of parsing a language is not the parsing, it is recovering from a syntax error and continue to generate meaningful errors. Especially mistakes with block constructs are difficult to deal with. Say a missing end-brace for a method body. So yes, languages that are more verbal about block syntax help compilers produce better errors.Fellah
I made a last-ditch edit to get a thorough, controversy-free answer to this question. If it's specific enough to reopen now I would greatly appreciate it.Scutcheon
K
5

I have experience/am responsible for building dozens of language front ends.

Wordy languages vs. punctuationy languages are generally equally hard to parse and statically analyze.

The folks that define languages of either kind have either been decorating them for decades (e.g., COBOL since 1958), or building sophisticated languages (C++, Scala, Ruby) with both complex syntax and complex name resolution and type inference rules; the compiler vendors then proceed to add obscure syntax to support the strange things they do or to provide a customer lock (e.g., MS "managed C++", DLL declarations, etc.). There's the third problem of lousy definitions; the top languages may have precise rules about how they work, but many languages have sloppy definitions (e.g., PHP) which creates dark corner cases that have to be ironed out by painful experimentation with the actual implementation.

C++ has been our worst, esp. with the C++11 committee making a massive recent mess of things. We have full C++ parsers, but are still working on full name resolution for C++11 on top of our C++98 implementation. (The name resolution code is some 250,000 lines of code and its not enough!).

IBM COBOL is a close second; the language is just giant, and there are all sorts of funny name resolution rules ("an unqualified name can refer to a particular name without qualification if the reference is unambiguous" So, is this name an unambiguous reference in this context?).

Once you get past parsing and name/type resolution, then you get into control flow, data flow, points-to analysis, range anlaysis, call graph construction, ... which are generally about the same amount of effort as the earlier phases; we get away with less by having really good libraries that support these tasks.

With all this as background analyses, you can start to do "static analyis" of the smart kind that people want.

Another poster noted that recovering from syntax errors and (emphasis) "continue to generate meaningful error messages". All I can say to this is "Amen, brother". See this SO answer https://mcmap.net/q/1780139/-static-analysis-for-partial-c-programs for a discussion of what goes wrong when you have "partial programs", which is essentially what you get when syntax error repairs guess at a fix.

Konstanze answered 22/5, 2012 at 17:23 Comment(2)
This is the answer I was looking for. All I can say is thanks for what you do, this sounds truly daunting.Scutcheon
A nice compliment, thank you. There are days that I rue this particular career choice :-}Konstanze

© 2022 - 2024 — McMap. All rights reserved.