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

* Re: [Caml-list] Tools for helping backward compatibility?
  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
  1 sibling, 1 reply; 5+ messages in thread
From: Hendrik Boom @ 2020-08-21 13:52 UTC (permalink / raw)
  To: caml-list

On Fri, Aug 21, 2020 at 02:19:10PM +0200, François Bobot wrote:
> 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.

I forget if OCaml lets you specify just exactly which names you import 
from a module.  But if it does, some editor features would be useful:

* to add code to an import specifying exactly the features that are 
  currently exported from the module to protect against future name 
  clashes if the module is augmented.
  * same with explicit specification of the types of imported names 
      to detect future tye changes)
    * (this might need a compiler change)
  * Or the same, listing only the names currently used by the importer.

Yes, these changes will likely need deep interaction between the editor 
and the compiler.

-- hendrik

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

* Re: [Caml-list] Tools for helping backward compatibility?
  2020-08-21 12:19 [Caml-list] Tools for helping backward compatibility? François Bobot
  2020-08-21 13:52 ` Hendrik Boom
@ 2020-08-22  4:09 ` Yawar Amin
  2020-08-24  8:51   ` François Bobot
  1 sibling, 1 reply; 5+ messages in thread
From: Yawar Amin @ 2020-08-22  4:09 UTC (permalink / raw)
  To: François Bobot; +Cc: OCaml Mailing List

[-- Attachment #1: Type: text/plain, Size: 960 bytes --]

Hi,

On Fri, Aug 21, 2020 at 8:19 AM François Bobot <francois.bobot@cea.fr>
wrote:

> ...
>   - 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
>

Do you mean something like Semantic Versioning here? See e.g. Elm which has
a package manager that can enforce SemVer by comparing types:
https://elm-lang.org/news/0.14

> For package authors, it means we can automatically enforce semantic
versioning. No user will ever get a breaking API change in a patch version
again!

Something like this for OCaml would be very cool. But I've heard that
SemVer for OCaml is either difficult or effectively impossible, indeed due
to some of the reasons you listed. I think any practical codification of
backward-compatibility rules would probably need to ignore the presence of
features like 'module type of' and 'include'.

Regards,

Yawar

[-- Attachment #2: Type: text/html, Size: 1437 bytes --]

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

* Re: [Caml-list] Tools for helping backward compatibility?
  2020-08-22  4:09 ` Yawar Amin
@ 2020-08-24  8:51   ` François Bobot
  0 siblings, 0 replies; 5+ messages in thread
From: François Bobot @ 2020-08-24  8:51 UTC (permalink / raw)
  To: Yawar Amin; +Cc: OCaml Mailing List

Le 22/08/2020 à 06:09, Yawar Amin a écrit :
> Do you mean something like Semantic Versioning here? See e.g. Elm which has a package manager that
> can enforce SemVer by comparing types: https://elm-lang.org/news/0.14


Thank you a lot for the pointer. Unfortunately I'm yet not able to find details about the tool (dead
links). Still:

$ elm diff Microsoft/elm-json-tree-view 1.0.0 2.0.0
This is a MAJOR change.

---- JsonTree - MAJOR ----

    Changed:
      - parseString : String -> Result String Node
      + parseString : String -> Result Error Node

      - parseValue : Value -> Result String Node
      + parseValue : Value -> Result Error Node


I think it is better to let developers choose how/if they want to mark in the version breaking
changes. Such tooling to detect problematic changes is already difficult without adding normative
bike-shedding.

I don't have the details of their tools, but it seems that a differences would be that the API
developers would have the ability to tell which changes are problematic, and so how the user of the
API can use it.

> 
>> For package authors, it means we can automatically enforce semantic versioning. No user will ever
> get a breaking API change in a patch version again!
> 
> Something like this for OCaml would be very cool. But I've heard that SemVer for OCaml is either
> difficult or effectively impossible, indeed due to some of the reasons you listed. I think any
> practical codification of backward-compatibility rules would probably need to ignore the presence of
> features like 'module type of' and 'include'.

SemVer is difficult or even impossible in OCaml if you don't restrict what the user of the API can
do with it. For any API change you can create a program that will be broken by it.

There is one case where you can use `module type of` and `include` without any backward
compatibility problem (except removing the library). Reexporting a library:

module A : module type of Lib = struct include Lib end

So if you don't have any guarantees, the only accepted use of `module type of Lib`, could be this
one. With more guarantees, other usual uses of `include Lib` can be accepted. For `module type of`
it is more contrived, like guaranteeing to not add new types and values.

But it is not a bad thing to forbid that for external libraries. For internal use those constructs
can always be used since all the modules of one library move in lock-step. Even libraries that are
guaranteed to move in lock step can avoid those restrictions between them.

Best,

-- 
François

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

* Re: [Caml-list] Tools for helping backward compatibility?
  2020-08-21 13:52 ` Hendrik Boom
@ 2020-08-24  9:18   ` François Bobot
  0 siblings, 0 replies; 5+ messages in thread
From: François Bobot @ 2020-08-24  9:18 UTC (permalink / raw)
  To: caml-list

Le 21/08/2020 à 15:52, Hendrik Boom a écrit :
> On Fri, Aug 21, 2020 at 02:19:10PM +0200, François Bobot wrote:
>> 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.
> 
> I forget if OCaml lets you specify just exactly which names you import 
> from a module.


Since https://github.com/ocaml/ocaml/pull/2147, which implements
https://www.cl.cam.ac.uk/~jdy22/papers/extending-ocamls-open.pdf it is possible to restrict easily
the names you are importing but you need to specify the type of each of them, which is quite verbose.


> But if it does, some editor features would be useful:
> 

> Yes, these changes will likely need deep interaction between the editor 
> and the compiler.

It could be fun to have the information automatically updated during the edition. The refreshing of
the precise import could also be done just once before any release.

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).