How should type-incompatible re-definitions work? #157
stylewarning
started this conversation in
Ideas and Proposals
Replies: 1 comment
-
Particularly in release mode, I don't think type incompatible redefinitions should be allowed. In development, yeah, a continuable error sounds good. I'm not even sure if even type compatible function redefinitions should be allowed. It doesn't seem to play nice with inlining, nor does it play nice with debugging - once a function is redefined, I'm not sure if there is a better way to find where the function's older definition than using find/grep. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Consider this:
Lisp is OK allowing this redefinition even though the type changes. How should we handle this?
Option 1
Do nothing. Just keep the behavior as-is.
This is maximally Lispy, but defeats some of the point of Coalton. I actually ran into this problem of THIH silently overwriting
COMPOSE
. (Would have been solved with a package lock.)Option 2
Issue a warning that a function is re-defined with a different type. This will make compilation units error if redefinition happens, but REPL interactions OK.
Option 3
Flat-out error. Bad user! (But make it continuable.)
Option 4
Error, but only if there are uses of that re-defined variable that conflict.
Beta Was this translation helpful? Give feedback.
All reactions