@wallhackio ​

@wallhackio anyway here is something i think about that to me complicates the nomenclature at play here

now, this is not the entirety of use cases fur exception handling, but a very compelling use case fur exceptions is to handle impawsible situations about as gracefully as pawsible—even if by just crashing. the way erlang does, i guess. put a pin in that

consider you are using a strongly typed language with algebraic data structures, in which it is natural to define a data type that represents an abstract syntax trees. assuming there are no bugs in the AST definition, any construction you can make in the AST that type checks is a syntactically valid statement in the language you are writing an AST fur

so, imagine trying to compile source code whose contents entirely consist of constructing an AST in this language. if this fails to compile, you are trying to repurresent a local impawsibility, and the compiler will stop execution

is it a valid way to think about compilation in general in these same terms? is a compiler error better thought of as an expected result, or as an error state resulting from the compiler being forced into a logically impawsible state by the context in which it is oppurrating? which is to say, is it valid to conceive of compile time errors as the compiler assuming it is oppurrating in a logically consistent world, and exploding in response to a discovered inconsistency?

@aescling i dont think there is a "right answer" to that question. all i will say is that, if i designed a compiler, i would treat the case of incorrect code as an expected outcome because i would want to inform the user as clearly as possible what was wrong

@aescling @wallhackio bitch just have your compiler return Maybe<AST> instead of exploding

@aescling @wallhackio anyway the only graceful handling of an impossible situation is a fatal error i·e immediate termination of the program. the very existence of the exception implies that the situation is both possible and foreseen