Remove dynamic type check in Static Binary instance. #16
Conversation
Currently, a dynamic type check occurs when a static value is deserialized. The reason for this check is to preclude writing pathological functions such as `decode . encode` that make it possible to modify the phantom type parameter of the static value. However, `decode . encode` is arguably the same pattern as `read . show`, which in general is unsafe (e.g. whenever phantom type parameters are involved) but not in any manner specific to static values. It is debatable whether we should defensively protect against the user writing such code through the use of extra Typeable constraints. For what is good for the goose is good for the gander, i.e. not just static values, yet we cannot hope to guarantee type safety whenever the representation of an abstract type is exported in any way. Moreover, this dynamic type check is redundant with a second type check that occurs when resolving static values, in 'unstatic'. One can construct all manner of static values and compose them, but they can only be used by resolving them. Hence a dynamic type check will occur at least once, i.e. at resolution time. There is, therefore, little value in doing a dynamic type check earlier, while each such type check has a non negligible performance cost.
|
I vaguely remember that this change has been discussed before, back when it was first proposed over 2 years ago. FTR one of the points in the discussion is that |
|
Correction: in the current implementation |
Authored by @mboes
Currently, a dynamic type check occurs when a static value is deserialized. The reason for this check is to preclude writing pathological functions such as
decode . encodethat make it possible to modify the phantom type parameter of the static value.However,
decode . encodeis arguably the same pattern asread . show, which in general is unsafe (e.g. whenever phantom type parameters are involved) but not in any manner specific to static values. It is debatable whether we should defensively protect against the user writing such code through the use of extra Typeable constraints. For what is good for the goose is good for the gander, i.e. not just static values, yet we cannot hope to guarantee type safety whenever the representation of an abstract type is exported in any way.Moreover, this dynamic type check is redundant with a second type check that occurs when resolving static values, in 'unstatic'. One can construct all manner of static values and compose them, but they can only be used by resolving them. Hence a dynamic type check will occur at least once, i.e. at resolution time. There is, therefore, little value in doing a dynamic type check earlier, while each such type check has a non negligible performance cost.