Adrian May <> wrote:

> How about this: can you guys give me a detailed example of a justified
> deprecation: one so extremely obviously called for that even I would
> agree. I just want to understand the kind of logic that's applied over
> these things.

Changes already made in the base library or in one of the platform

  * base: Eq and Show independent of Num.  Broke a lot of code.  Reason:
    Makes function-like numeric types possible.

  * base: Deprecated and finally removed the old exception system.
    Replaced by extensible exceptions, added new masking system.  Broke
    a lot of code.  Reason:  Makes the whole exception handling more

  * mtl: Unified transformer and Identity variants.  Broke some code.
    Reason:  Makes the internals much more maintainable and the whole
    library design more sensible.

  * Haskell: Changed the type specializing behavior in local bindings.
    Broke a lot of code.  Reason:  Makes type inference infer more
    specialized types, makes code more concise, but occasionally
    requires a type signature when you specifically want more
    polymorphic types.

Often demanded changes that may or may not happen in the future:

  * base: Make Functor a superclass of Monad.  One of the two most
    commonly demanded change to the base library.  Will break lots and
    lots of code.  Reason:  Would greatly simplify a lot of code.

  * base: Fix the numeric type classes.  The other most commonly
    demanded change.  Will break lots and lots of code, including most
    of the base library.  Reason:  Would make numeric code much more
    sensible and algebraic.

My personal demands.  Unlikely to happen in the near future:

  * Add RankNTypes, ScopedTypeVariables, TupleSections and TypeFamilies
    to standard Haskell.  Shouldn't break any existing code.

  * Replace all special arrow classes by category classes, i.e. turn
    ArrowChoice and ArrowLoop into CategoryChoice and CategoryLoop.
    Introduce ApplicativeFix.  Will break some existing code.

  * Factor Applicative and Alternative into four classes:
      - (Functor f) => Apply f          (<*>)
      - (Apply f)   => Applicative f    pure
      - (Functor f) => Plus f           (<|>)
      - (Plus f)    => Alternative      empty
    Would break everything.  Everything.

I could go on.  The point is that you are probably the first person to
complain about those changes. =)


Not to be or to be and (not to be or to be and (not to be or to be and
(not to be or to be and ... that is the list monad.

Attachment: signature.asc
Description: PGP signature

Haskell-Cafe mailing list

Reply via email to