This is an automated archive made by the Lemmit Bot.

The original was posted on /r/programminglanguages by /u/useerup on 2023-10-19 10:23:32.

When designing your language did you consider how accurately the compiler can pinpoint error locations?

I am a big fan on terse syntax. I want the focus to be on the task a program solves, not the rituals to achieve it.

I am writing the basic compiler for the language I am designing in F#. While doing so, I regularly encounter annoying situations where the F# compiler (and Visual Studio) complains about errors in places that are not where the real mistake is. One example is when I have an incomplete match ... with. That can appear as an error in the next function. Same with missing closing parenthesis.

I think that we can all agree, that precise error messages - pointing to the correct location of the error - is really important for productivity.

I am designing my own language to be even more terse than F#, so now I have become worried that perhaps a language can become too terse?

Imagine a language that is so terse that everything has a meaning. How would a compiler/language server determine what is the most likely error location when e.g. the type analysis does not add up?

When transmitting bytes we have the concept of Hamming distance. The Hamming distance determines how many bits can be faulty while we still can correct some errors and determine others. If the Hamming distance is too small, we cannot even detect errors.

Is there an analogue in language syntax? In my quest to remove redundant syntax, do I risk removing so much that using the language becomes untenable?

After completing your language and actually started using it, where you surprised by the language ergonomics, positive or negative?