Library deprecation (was: RE: monad library)

[John Meacham]

There is another more radical suggestion we might want to consider.
explicitly versioned interfaces.

something like 
import Control.Monad.2.0

which will match the greatest numbered library which starts with 
Control.Monad.2.

the version numbers being standard major/minor type version numbers for
just INTERFACE changes. not internal ones.

this would also make forward compatable programs much easier, since
older apis can still be exported without interfering with newer ones.


Of course, what I would really like is the ability to include by GUID
for instance any module with a {-# GUID <foo> optional-export-list... #-}
would ALWAYS be available as 
import GUID.<foo> and would only import those symbols listed in the
export list of the GUID pragma. 

this would solve most all problems as modules just create a new guid and
have multiple GUID pragmas for each distinct interface (including their
'past' interfaces) they support. for best results, the export list
should support aliasing internally. so you could do things like having
these in the same module.

{-# GUID dbd159ce980a69ba5008 foo, bar, baz #-}       -- new interface
{-# GUID 111d5b80771eea99cd7d foo, old_bar as bar #-} -- old interface

actually, I would really like to see the GUID thing listed above
included in current compilers as an extension (moreso than versioned
interfaces) as it could greatly increase the robustness of haskell
programs.

        John



On Wed, Jul 30, 2003 at 10:34:25AM +0100, Simon Marlow wrote:
> Malcolm Wallace writes:
> > ... so the question here
> > is really about the process for deprecating one existing API and
> > replacing it with a new API.  I don't have a solution to this issue.
> > However, it is clear that allocating a new namespace every time a
> > API is improved, is a recipe for confusion amongst users when they
> > search for "the" API without a knowledge of the social history.
> 
> Agreed.
> 
> It seems to me that we do need a way to have multiple versions of an API
> available, however.  We can do this two ways:
> 
>  1. Use a top-level name 'Old', for old versions of libraries.  The
>     contents of Old would mirror the top-level hierarchy, so eg.
>     Old.Control.Monad would be the previous version of the Control.Monad
>     library.  This extends nicely to allowing even older versions:
>     Old.Old.Control.Monad :-)
> 
>  2. Use a suffix instead.  For example, Control.Monad.Old would be
>     the previous version, and would import Control.Monad.Trans.Old, etc.
> 
> (1) means you can retain the structure of the original hierarchy inside
> Old, and different versions of APIs are completely separate.  (2) means
> less moving around of source files.  On balance, think I prefer (1).
> 
> Cheers,
> 	Simon
> 
> -- 
> Libraries mailing list
> Libraries@haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
> 

-- 
---------------------------------------------------------------------------
John Meacham - California Institute of Technology, Alum. - john@foo.net
---------------------------------------------------------------------------