[Caml-list] Tools for helping backward compatibility?

["François Bobot" <francois.bobot@cea.fr>]

Hi all,

  Backward compatibility helps a lot a community of packages to move forward. There are other
possibilities like being able to co-install multiple version of a library, but having backward
compatibility is still a huge simplification of the problem.

  Strongly typed language makes it easier to break backward compatibility since more things are
checked, dynamically typed language let more thing pass for the best and too often for the
unpredictable worst. So I'm discussing here only backward compatibility at the typing phase.

  I'm wondering if typing have been used for helping to ensure backward compatibility of an API. In
a sense it is at the core of the module system, adding a signature to a module ensure that whatever
you change in the implementation if you don't modify the signature any user is going to type.
However it doesn't help you if you modify the signature:

  - Changing anything meaningful in a module can break someone who uses `module type of`.
  - Adding a type can break someone who includes the module
  - Adding an optional argument to a function can break someone who uses it not fully applied.
  - Removing a value from the definition of a signature can break someone who uses it as a functor
parameter
  - Adding a constructor breaks all matching without final wildcard

 However they are modifications of an API that could be seen as normal and should not break sane
user. In order to not have to cross our fingers, we could specify how we could modify in the future
our API so that users are warned when they use the API in a way that could be broken in the future:

  - In the future this type will not be modified: so the user can pattern match all the cases
  - In the future no new values will be added: so the user can open the module as much as you want
  - In the future new cases can be added to an ADT: so the user need to use a _
  - In the future optional arguments can be added to the values of this module: so the user need to
apply fully

Then three checks can be provided:
  - Given an API, the guarantees of the possible modifications of the API, and a user code: check if
the user code can be broken by future modifications of the API
  - Given an API, the guarantees of the possible modifications of the API, and a new version of the
API: check if the new version follows the guarantees
  - Given an API, the guarantees of the possible modifications of the API, and new guarantees of the
possible modifications of the API: check if the new possible modifications are included in the old one

 I believe the analysis can be done after the normal OCaml typing (on typedtree), so it can be
external to the OCaml typer. But it still put pressure on what the Ocaml typer does accept.


(Perhaps "API migration: compare transformed" at OCaml 2020 next week will have some answers!)

Best,

-- 
François