Changes between Version 4 and Version 5 of Defaulting

Nov 20, 2006 11:55:24 AM (9 years ago)

Add two new proposals for defaulting


  • Defaulting

    v4 v5  
    12= Defaulting = 
    5354 * can not exactly replicate behavior of existing defaulting mechanism, but can come close. 
    5455 * might hide errors, an optional warning on defaulting should be possible. 
     58== Proposal 2 == 
     60Change the syntax of the defaulting clause from: 
     62topdecl  ->  default ( type_1 , ... , type_n ) 
     66topdecl  ->  default ( tycls_1 => type_1 , ... , tycls_n => type_n ) 
     68Semantically, which type is chosen is determined by the class context at the choice point (after context simplification).  If there is no unique choice, for instance because more than one class-with-a-default is mentioned in the context (and their default types are different), then it is a static error.  Note that it is OK to have several classes in the context of the defaultable value, provided only one of them is declared to yield a default type, or if more than one yields a type, those types are the same.  Choosing a default after context simplification means that no conflicts between super- and sub-classes can arise. 
     70The current Haskell'98 default-default behaviour can be specified as: 
     72default ( Num => Integer 
     73        , Real => Integer 
     74        , Enum => Integer 
     75        , Integral => Integer 
     76        , Fractional => Double 
     77        , RealFrac => Double 
     78        , Floating => Double 
     79        , RealFloat => Double 
     80        ) 
     83=== Pros === 
     84 * less ad hoc than current method 
     85 * overcomes the Hat transformation problem 
     86 * does not rely on textual ordering of decl 
     87 * permits defaulting of user-defined classes, not just Prelude ones 
     89=== Cons === 
     90 * not sure if this exactly captures the existing Haskell'98 module (but because defaults are currently limited to Prelude classes, it probably does). 
     92== Proposal 3 == 
     93Orthogonal to the issue of how to specify defaults, is the question of whether they should be module-local, or if instead we should treat them like instance declarations - global in scope.  One can also imagine permitting explicit lexical scoping, i.e. a local override of the defaults, purely within a single function definition. 
     95Concrete proposal:  a default decl can occur anywhere that a type signature would be valid, and has the same scope.  However, because default decls cannot be named, all default topdecls must be unique throughout a program.  By contrast, a local default decl can override one at an outer scope, but only within its own inner scope. 
     97=== Pros === 
     98 * Arguably, when user-defined classes and types are involved, it is a lot clearer to make any necessary default decls once only, in a library, and just have them apply everywhere, rather than to require end-users to understand the issues and make their own default decls. 
     99 * Having consistent defaults throughout a program is semantically nicer (but you still get the opportunity to override them locally if you _really_ need to - just like with operator fixities). 
     101=== Cons === 
     102 * Changes the Haskell'98 behaviour (where defaults are module-local).  Question: Do any real programs actually rely on the Haskell'98 spec here?