News for hackers. Stuff that matters.
Re:Learning Elm has gotten me confused about static vs. dyna... by dllthomas on Wednesday June 15, 2016 @12:20PM (#11910233)
That's what I had understood you to mean; what I was unsure of is whether you intended this to be the only mode of compilation - and addressed what seemed like each possibility in the second half of my post.
Re:Learning Elm has gotten me confused about static vs. dyna... by kazinator on Wednesday June 15, 2016 @12:55PM (#11910451)
Sure, only mode. Inform me "this program is not known to be well-typed" or "this program is outright ill typed". Then, let me run it anyway, and correctly detect the consequence of the admonition with run-time info. Or I could choose not to run that program; I want mine well-typed.
Re:Learning Elm has gotten me confused about static vs. dyna... by dllthomas on Wednesday June 15, 2016 @01:25PM (#11910660)
In the presence of -Werror, this seems isomorphic to the notion of adding a '-fdynamic-type-errors' flag.

It can't be done in full generality because, as I mentioned, there are places where term-level values depend on types. If we don't know what type, we can't know what term.

We could certainly treat only those situations where behavior is ambiguous like '-fdefer-type-errors' currently treats any type mismatch, and add dynamic checks for the rest. It would be an interesting point in the space, though not one I would expect to use very often.