[plt-scheme] On PLaneT packages and compatible upgrades

On May 10, Matthew Flatt wrote:
> What if we had a way to make exports version-specific?
> [...]
> (I don't how to implement `provide-version', but that's a secondary
> question.)

Seems irrelevant now, but FWIW, implementing this is possible using
the same mechanism that hides unsafe foreign.ss bindings until you
declare your code as (unsafe!).  (And this still interacts badly with
providing all-defined.)


On May 10, Matthew Flatt wrote:
> At Wed, 10 May 2006 07:58:01 -0400, Matthias Felleisen wrote:
> > I would very much prefer a tool -- "Compatible Extension" -- that
> > consumes two modules and either says "yes" or lists the things
> > that one module exports and the other doesn't. In addition, it
> > should come with an option "Generate Adapter," which produces a
> > module m- with the same interface as m.v0 but with values from
> > m.v1. (This should be N+2 lines: module, import plus one export
> > per m.v0 interface.)
> 
> This took me a while to understand. I'll repeat it back just to see
> if I do understand:
> 
>  1. Adding exports is not a compatible upgrade.
> 
>  2. Suppose the only change between version N.M and (N+1).0 is bug
>     fixes plus new exports. In that case, it's trivial to implement
>     version N.(M+1) in a way that captures future bug fixes in the
>     (N+1).* series: import (N+1).*, then re-export everything that
>     was exported from version N.M.
> 
>  3. Since the implementation of N.(M+1) is trivial given N.M and
>     (N+1).0, it would be nice to have a tool that does it for you.
> 
>  4. Also, library implementors should also use a tool to double-check
>     that any implementation K.(J+1) is a compatible extension of K.J
>     (i.e., it has the same exports).
> 
> Is that right? If so, I like it.

What I don't like about all this is that it's based only on names.  I
also don't like the assumption that using version (N+1).K it is
possible to `compute' version N.(M+K) -- it feels like a fragile
assumption, and it doesn't feel right to generate automatic versions
where the author didn't mean for them to exist (=> how would you feel
about an automatically created PLT v210?).

What if I want to remove bindings, or change the way some existing
binding behaves, like adding an argument or changing what it does?
(Being pedantic about names means that I won't want to open a
thesaurus or have functions named `foo2' or `new-foo'.)

What I would prefer is that every time I release a new version N+1, I
provide my own version N compatibility layer in the form of a new
module -- in most bug-fix-only cases this module does nothing, and in
other cases it can remove bindings, add them, or change them.  Given
such a file for every new version would make it possible to chain
previous compatibility modules so it is possible to get any version.

-- 
          ((lambda (x) (x x)) (lambda (x) (x x)))          Eli Barzilay:
                  http://www.barzilay.org/                 Maze is Life!