4 ms·
>* you can never be certain that the maintainer actually follows it Elm enforces semantic versioning with its type system, and one can also print the diff of v
by bauerd 9y ago
>* you can never be certain that the maintainer actually follows it
Elm enforces semantic versioning with its type system, and one can also print the diff of values/functions between separate package versions. In principle, this is doable.
- JonathonW 9y agoAPI compatibility (showing that a package contains the same functions, which accept the same kinds of inputs and produce the same kinds of outputs) is only part of the problem-- it's harder to show that the functions actually do the same thing, but that's arguably more important than API compatibility. Typically, a compiler will catch a breaking API change; a behavior change will cause problems at runtime if a function suddenly starts doing something completely different.
- bauerd 9y agoYes, true. But still, having the compiler reject breaking changes when there should be none already goes a long way
- baddox 9y ago> it's harder to show that the functions actually do the same thing Effectively impossible, with a Turing complete programming environment. (“Effectively,” because technically our physical computers have a bounded number of states and inputs, thus aren’t technically Turing complete, thus Rice’s theorem technically doesn’t apply.)
- TylerE 9y agoThere are however tools like QuickCheck (https://hackage.haskell.org/package/QuickCheck https://hackage.haskell.org/package/QuickCheck) that can bombard the function with large amounts of random (but legal) input data and makes sure it's behaving.