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.
[ Parent
| on HN ]
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.