John Lato schrieb:

...

Encouraging people to use bleeding edge APIs just contributes to the already dicey problem of writing future and backwards compatible code in Haskell, in fact, writing to haskell 98 is the _only_ option at the moment with any ability to do so.

I was originally in favor of deprecating haskell98 but didn't care enough to voice an opinion. John's argument has convinced me otherwise, so +1 to keeping haskell98.

This would be compatible with the method "warn about packages that depend on both haskell98 and base".

On Thu, Mar 11, 2010 at 11:25 AM, John Lato wrote:

I was originally in favor of deprecating haskell98 but didn't care enough to voice an opinion.  John's argument has convinced me otherwise, so +1 to keeping haskell98.

In the Standard ML world, there was some traction on the idea of ML Basis (MLB) files http://mlton.org/MLBasis The concept is, superficially, to support linkage and module work "in the large" contrast to "in the small" which most module systems are about. As an example, you can pull a set of modules and in the process rename them such that they do not conflict with yours. Or you can do the opposite and export modules under different names than what you used internally. The real killer in this discussion is the ability to include a module hierarchy from an older version of the standard library. Writing local $(SML_LIB)/basis/basis-1997.mlb in prog.sml end gives you the old (deprecated) SML Basis, whereas the declaration local $(SML_LIB)/basis/basis.mlb in prog.sml end gives you the newest basis hierarchy. Thus in effect, the system supports the old code through a simple redeclaration of what library to pull in. More information is available at the link above, including examples of how to support module import/export renaming. -- J.