caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
* [Caml-list] Tools for helping backward compatibility?
@ 2020-08-21 12:19 François Bobot
  2020-08-21 13:52 ` Hendrik Boom
  2020-08-22  4:09 ` Yawar Amin
  0 siblings, 2 replies; 5+ messages in thread
From: François Bobot @ 2020-08-21 12:19 UTC (permalink / raw)
  To: OCaml Mailing List

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

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2020-08-24  9:19 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-08-21 12:19 [Caml-list] Tools for helping backward compatibility? François Bobot
2020-08-21 13:52 ` Hendrik Boom
2020-08-24  9:18   ` François Bobot
2020-08-22  4:09 ` Yawar Amin
2020-08-24  8:51   ` François Bobot

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).