What would a language that "always compiles" and "never crashes" look like? Where there is no such thing as a syntax error, type error, or runtime error? Where every text string (or AST) is executable? I'm thinking this can be done with a compositional approach to errors: instead of crashing when a result is undefined (due to syntactic or semantic errors), return an "undefined" value, which in turn poisons all of the expressions it is used within, similar to how NaN works. Would such a semantics have merit? It would let you run incomplete programs (like Hazel), and also let you recover from errors (with the equivalent of an isNaN() function). But perhaps most importantly, it would be a good foundation for a live & persistent programming environment: if there is no need for code to be checked prior to execution, then there doesn't need to be a "compile time". This doesn't make programs harder to reason about: a programmer can still use static analysis tools (incl. "type inference") to understand and enforce runtime behaviour (e.g. verifying/requiring the absence of "undefined").

This pattern is common in dataflow languages

The title of that Go post is perhaps deceiving, since their approach to errors is just the same old approach that C code uses: an error is a separate return value that must be checked in order to be noticed. It is not compositional, and Go programs still crash in a myriad of ways.

LabVIEW (a dataflow language) has errors that are just another value returned, although it does not always compile because it runs a type propagation algorithm that will break your code if the types don't match up. But it is always compiling in the background, ready to run if it can. If an error is returned, the program doesn't crash and they aren't exceptions. You can ignore the error, process it, generate a more specific one, etc. However, it still has the problem of the developer not knowing what errors could be generated, which is a problem in every language I have ever used, and a tough problem. I'd love a language that specifically separated functions between those that can and cannot return errors. Functions that can return errors should return them as values and the documentation should list exactly why and when an error is returned. Additionally, the errors should be pattern matchable.

I'd love a language that specifically separated functions between those that can and cannot return errors.

Most functions beyond the identity function and constants can return errors: you simply have to pass them a value that is not part of their domain 🙂. Sometimes the domain is tricky: for example the div instruction takes all numeric divisors apart from zero, and it's often hard to statically verify that zero won't be given. That's perhaps the simplest use-case for an "undefined" return value. But if a value is explicitly considered part of the domain, yet can still induce some "error-like" result (for example, failure to pass a JSON string), then I agree they should probably return a specific error value that distinguishes this class of error from the more general "I passed a string to a function expecting an integer" undefined result.

Runtime errors are a fundamentally optional concept. There's not necessarily a concept of an error in a Turing machine: the closest thing is if you hit a gap in your transition table, but you can fill those in with any default that strikes your fancy. In a more conventionally shaped language, that probably means ignoring or no-opping any state or operation you don't understand.... so yeah, it looks like JavaScript, but more so. I haven't tried it, but om-language.org claims to have the property that all UTF-8 strings are valid OM programs. Unclear how it handles errors, but the words "error", "fail", "halt", and "stop" are absent from its front page.

I think an absent transition in a Turing machine should be considered the same as crashing: the machine cannot proceed from that point. Looking more broadly at imperative languages, it's probably only those with structured control flow can "back out" and continue after an error: just jump past/out of the current structure (block, function, etc). Turing machines don't really have a good option. I should point out though, that I was specifically thinking about declarative languages (those based on composable expressions) as I wrote my original post. I'll check out Om 🙂

A language consisting only of "print" statements. And since that is the only operation, the syntax for a print statement is just the text to be printed. Each statement is on its own line. Each statement prints a new line of text. The statement to print an empty line of text, is an empty line of text. This language has well defined syntax and semantics, and every input program is valid.

There's a good talk from I think Strange Loop which is basically the system @Andrew F describes. It's a sort of infinite stack of Lisp interpreters. Whenever an unhandled error occurs, it doesn't crash, it bumps you up one meta-level and gives you a chance to "explain yourself". Unfortunately I can't remember the speaker's name so I can't find it now... I think she might actually be on the Slack.

I think you might be referring to this talk by Nada Amin:

the behavior @Andrew F describes is pretty much exactly how smalltalk works:

you might also be interested in the "typed holes" concept that Darklang and others have been pushing forward, its not quite error-less but it is a lot closer to runnable-while-incomplete programs

Combining "no syntax errors" and "composable expressions" might be actually impossible. I'm guessing you would start by dealing with the case when you can't tell where an expression ends and the outer one it is composed with resumes. Or maybe mandatory structured editing.

@Harry Brundage Typed holes are interesting. Hazel (which I linked earlier) is perhaps the most interesting iteration of the idea, because it propagates erroneous subexpressions (instead of crashing), and shows you them in the output. However, I don't believe they've developed a means of programmatically recovering from (responding to) such an error. Their goal is mainly to aid code comprehension and debugging.

Oh! How about Leet? https://en.m.wikipedia.org/wiki/Leet_(programming_language)

@Andrew F tree languages have no such thing as syntax errors and are very composable.

@Dan Cook I think we have a divergence of mind here. You're referencing zany toy languages, whereas I'm interested in languages for real work 😂

what about Idris? I don’t know much about it, but it seems you can treat exceptions as values http://docs.idris-lang.org/en/latest/effects/simpleeff.html#exceptions

@Nick Smith I wasn't just be silly for the sake of being silly, I was also making a point. What I'm saying (humor aside) is: What really is a program? What's structure? I can achieve that with exact 1:1 perfection but accomplish nothing meaningful (the print example), or have a Turing complete solution that seems like a joke on the surface, but is actually a quite practical solution (Leetcode). Of course, the first can be replaced with just print statements, and the second with just digits which is basically just a reinvention of machine code. Sounds pointless, but they fixed what's been identified as a real problem at hand. But is the problem really in the programming language, i.e. the thing with well defined and unambiguous kinds of pieces and rules for fitting them together? Or is it the medium? How about an editor where all the different parts of a program are composable like building blocks? Only things that "fit together" can go together. I think Steve Kraus did something about "Types are shapes", and I think someone else here did something about "typed holes"? Anyway, I realize I'm taking about solving the problem from there other end (and I understand the merits of textual code in "the real world" as it sits today), but I'm just offering a perspective that what if this was treated from the source rather than the sink? I guess that's the same question (and similar topic in a way) as to why people feel strongly one way or the other (or in different contexts) about static vs dynamic typing. Seriously also explore that thought-space and see what maps back to this one (i.e. only allowing valid syntax vs dealing with any syntax).