It seems to me that you've just invented a static type checker. (Combined with a run-time type checker.) Am I mistaken?

I mean, we can argue the semantics of what, exactly "static type checker" means, but...

Static checking doesn't make a "static language".

A "static language" occurs when we have a model of program execution that involves erasing all of the type info before run-time. Or most of it. (Some static languages support OOP, and so stuff some minimal type info into objects for dispatch.)

Note how above, my expression executes anyway; the checks produce only warnings. The warning for the lack of a binding for the a variable is confirmed upon execution; the non-existence of the slot isn't since evaluation doesn't get that far.

If we retain the type info, we have dynamic typing. There is no limit to how much checking we can do in a dynamic setting. The checking can be incomplete, and it can be placed in an advisory role: we are informed about interesting facts that we can act on if we want, yet we can run the program anyway as-is.

This really sounds like "semantics" to me (not PL semantics! :).

For example, these days it's quite possible to ask GHC to defer type errors to runtime. Does that mean that the GHC dialect of Haskell is dynamically typed? This is basically a command line switch away, btw.

Retention of type information does not "dynamic typing" make. As a trivial example, consider C++ RTTI.

You really have just reinvented static (type) checking and a good runtime. There's no shame in that, but let's not pretend that these are opposing forces.

C++ RTTI is only for class objects, and only useful when they are manipulated by pointer or reference. I believe I covered that sort of thing with my statement, "Some static languages support OOP, and so stuff some minimal type info into objects for dispatch.". It's a gadget which provides an alternative to the structure of doing everything via virtual functions on a base class reference.

Ok, fair enough, but what about e.g. "-defer-type-errors" for GHC?

I still think you're just arguing semantics.

EDIT: Incidentally, the statically typed crowd can even go the "other way", namely from runtime -> compile time. For example, it's quite possible to derive a static proof/type from a runtime value in e.g. Idris by pattern matching as long as you're meticulous about building up the proof.

Not sure it's really an invention, it's been around for awhile. Check any decent common lisp implementation.

I'm pretty sure he doesn't mean invented in a literal sense. The phrasing implies a meaning of reinvented.

Correct, I was being a little bit facetious. All in good fun, obviously :).

>There is dynamic and then there is crap dynamic. (...) There is crap static too.

Excellent. My point exactly. I have no fear of using a static or dynamic language, as long as it is a good implementation of a statically (or dynamically) typed language.

What would you consider good implementations of either?

Good "statics": Haskell, ML family, maybe Rust.

Good "dynamics": All the Lisp-family languages. Smalltalk. Julia. Lua. Tcl.

Plus you can eliminate all typos in any language with a simple statistical linter that you can implement in like an hour or two.