3 ms·
> works with incomplete and incorrect code I know that this is a standard assumption, but I personally believe that it is a mistake to support this use case. I
by norir 4y ago
> works with incomplete and incorrect code
I know that this is a standard assumption, but I personally believe that it is a mistake to support this use case. It is a holdover from the batch processing days when getting feedback on your program could take minutes or hours. In those conditions, it was absolutely essential to try and proceed with a partial compilation even in the presence of errors or else iteration would have almost been impossible.
Now we live in an era of fast personal computers. With a language that is designed from the ground up with IDE support/rapid iteration in mind, you can get feedback with every keystroke. Everything is easier to design if you abort immediately on the first error, whether it is syntactic or semantic. Designing a parser with error recovery from syntax errors is a particularly dark art. On some level, you have to resort to guessing. It may work _most_ of the time, but to me there is nothing worse than a tool that is maybe correct.
When you advance past an error all of the code below the error is suspect. To give a trivial example, let's say you rename a function with 100 call sites without some kind of refactoring (automatic or manual). What benefit is there in showing the 100 new failures when the root cause is exactly where your cursor already is? There are cases like this that are even subtler where you are bombarded with downstream error messages that are confusing and taking you away from the actual root of the problem (c++ template errors come to mind). You may as well just gray out everything below the first error and reprocess it only when the error is fixed.
- IshKebab 4y agoI think you have misunderstood. He's talking about IDE support. IDEs absolutely must be able to understand incomplete or incorrect code otherwise code completion will be completely useless. You literally only need code completion when your code is incomplete. The clue's in the name.
- norir 4y agoI am focusing on the incorrect part. Let's say that you are adding some source code in the middle: ... def add(x: Int, y: Int) = x + y ... let x = ad|> I am using |> to denote the cursor location ... I agree that where the |> is that the IDE should be able to autocomplete `add` for you. What I am saying is that it shouldn't process anything below the let statement because the code is broken there. Many IDEs and compilers will continue processing the file after the first error so that they can report all of the findings. That is what I am suggesting they not do.
- Denvercoder9 4y agoIf you stop processing at that point, you can't autocomplete any functions that are defined further down in the file.
- norir 4y agoExactly. That is a feature.
- Denvercoder9 4y agoMaybe for you, but I'd consider that a pretty annoying bug. I like to structure my files/classes/modules in decreasing order of abstraction: put the public API and high-level algorithms at the top, and then dive into the minutiae how the various parts are implemented as you scroll down. That also means I almost exclusively call functions that are defined further down in the file.
- norir 4y ago> I like to structure my files/classes/modules in decreasing order of abstraction: put the public API and high-level algorithms at the top That makes sense. What I am describing doesn't preclude this organizational structure. It depends on the language design. You could either support c style forward declaration that you put at the top of the file and would be available for completion even if the implementation is below the first error in the file. Or the IDE could provide folding of the implementation so that you can scan the api without drilling down into the details. > That also means I almost exclusively call functions that are defined further down in the file. Again, to clarify are you calling things before they are _declared_ or _defined_?
- Denvercoder9 4y agoMost languages don't make a distinction between declaration and definition, and many don't even care where something is defined/declared at all. C/C++ are really the exception nowadays, and for good reason: having to keep the definition and declaration in sync is annoying and unnecessary, even though I sometimes miss the easy overview of an API header files give.
- hinkley 4y agoI've had this conversation a few times over beers: I think we are collectively Doing It Wrong by not considering code edits as deltas and checkpoints. Diffs often seem to fail to represent the actual change because they consider the delta from the last commit, which isn't the way we write code most of the time. If I go and insert a bunch of closing braces into the middle of a function, it's almost always because I'm dividing the function into two functions, or adding some missing error handling, or a corner case. So from the standpoint of a DAG representing the parse of the file, most of the time I expect the functions above and below to still be available in autocomplete even if I haven't balanced the tokens representing code blocks yet. If you saw a bunch of functions and I break one, I expect the IDE to consider the function broken, not the file.