Actually yes, you can pass a compiler flag, -fdefer-type-errors, which makes type errors turn from compilation errors to simply warnings. That said, any code that does not type check will also not run and instead will throw an exception at runtime if called (laziness is key here). But if Part B was giving type errors and you only cared about testing Part A, then you are good to go.

Yep. It's easier to implement and makes more sense in a lazy language than what you're describing though. I don't use it in my work but I do use a related technique to isolate what I am focused on fixing.

To elaborate a little on this:

In a strict language, a type error would mean the bricked off expression that doesn't type-check would spread like an infection to any expression that incorporated it.

In Haskell, I can dance around sub-expressions that don't type-check at runtime and evaluate things optionally.

The technique doesn't work in practice otherwise.

> The technique doesn't work in practice otherwise.

I don't see why. Functions in a strict language are evaluated lazily. Any type error within a function wouldn't spread beyond that function.

Values still wouldn't work. You'd have to change their types to `() -> whatever` and that means a lot of churn.

Even strict-by-default languages that let you easily make values explicitly lazy would mean type level churn, if not term level.

The value part is important because it means you can't really talk about partially implemented hypothetical results where you know how to handle one branch of a function, but not another. This is a super common divide-and-conquer technique in Haskell.

Could possibly half-ass it if you have some kind of panic functionality, but it'll fail unconditionally in a strict language when the result of the function is forced. In Haskell, if you don't use the bottom, it doesn't blow up.

Yes. You can defer type errors. I turn this on in development.