Meta-point: backward compatibility

Manuel M T Chakravarty chak at
Wed Apr 23 22:33:39 EDT 2008

Simon Marlow:
> Johan Tibell wrote:
>> An interesting question. What is the goal of Haskell'? Is it to, like
>> Python 3000, fix warts in the language in an (somewhat) incompatible
>> way or is it to just standardize current practice? I think we need
>> both, I just don't know which of the two Haskell' is.
> As for the particular question of backwards-incompatible changes,  
> here are some criteria that Henrik Nilsson proposed early on, and I  
> think are still relevant (i'm sure he won't mind my reposting these  
> from the committee mailing list):
> * If a proposed change breaks backwards compatibility, then it is
>   acceptable only if either
>   - very little existing code is likely going to be broken in
>     practice, or
>   - + it is widely agreed that not addressing the issue really
>       would harm the long-term relevance of Haskell', and
>     + it is widely agreed that attempting to maintain backwards
>       compatibility would lead to an unwieldy language design, and
>     + the proposed design and its implications are well understood,
>       i.e. it has been implemented in at least one system and it has
>       been used extensively, or a strong argument can be made on
>       the grounds of, say, an underlying well-understood theory.

As I have argued before on the committee list, I also think we should  
*not* worry about backwards incompatible changes too much in cases  
where a simple automatic translation from H98 to H' code is possible.   
Even for a large project, it is IMHO no big hardship to run a H98->H'  
translator over all Haskell sources.  After all, this is only needed  
for active projects that want to make use of H'.  For old code, I  
expect that compilers will still provide a -XHaskell98 flag or similar  
for the foreseeable future.

As John Launchbury has said, given Haskell's current rise in  
popularity, anything that we do not fix with H' will be much harder,  
if not impossible, to fix in the future.


More information about the Haskell-prime mailing list