Changes between Version 5 and Version 6 of Defaulting


Ignore:
Timestamp:
Nov 21, 2006 10:49:23 AM (7 years ago)
Author:
malcolm.wallace@…
Comment:

add some examples, tidy up the intro motivation

Legend:

Unmodified
Added
Removed
Modified
  • Defaulting

    v5 v6  
    44[http://www.haskell.org/onlinereport/decls.html#sect4.3.4 Ambiguous Types, and Defaults for Overloaded Numeric Operations] in the Haskell 98 Report. 
    55 
    6 For removal: 
    7  * Defaults are limited to certain classes.  A tool like Hat, which transforms Haskell source, cannot transform the defaults, because there is no way make defaults apply to the transformed classes rather than the original ones. 
     6Problems with the current defaulting rule: 
    87 
    9 For fixing: 
    10  * Report specification when it comes to defaulting is impossible to implement when general recursive modules are allowed. 
    11  * It should be specified that a group of mutually recursive modules must have exactly the same defaulting. 
     8 * Defaults are limited to Prelude numeric classes.  A tool like Hat, which transforms Haskell source, cannot transform the defaults, because there is no way make defaults apply to the transformed classes rather than the original ones. 
    129 
    13 For replacement: 
    14  * Perhaps require a default clause to name the class being defaulted over, as well as the type to choose. 
     10 * Defaults cannot be applied to user-defined classes.  It would be nice for some applications to be able to allow a default clause to name the class being defaulted over, as well as the type to choose.  Examples include QuickCheck, where you might wish to default the Arbitrary class to something small (e.g. Bool) when a value is otherwise unconstrained. 
    1511 
    16 Other issues: 
     12 * Report specification of defaulting is impossible to implement in the presence of recursive modules.  (Should it be specified that a group of mutually recursive modules must have exactly the same defaulting?) 
     13 
    1714 * A default clause applies only within the module containing the declaration.  Defaults can be neither 
    1815   exported nor imported.  Does anyone wish to propose import/export of defaults? 
     
    2118   * A compromise might be to allow defaults which will be inherited to be specified only in the module that defines a class, but groups of mutually recursive modules may override defaulting locally. this will avoid the import changing behavior problem and allow some sort of inheritence of defaults. 
    2219 
    23 == proposal 1 == 
     20== Proposal 1 == 
    2421 
    2522Allow defaulting clauses of the following form 
    26  
    2723{{{ 
    2824default <classname> (type1,type2,type3,...) 
    2925}}} 
    30  
    3126The defaulting rule will simply choose the first unambiguous type that satisfies all the constrained classes 
    3227listed in the default decls. 
     
    3429Classes without defaults will have the equivalent of an empty list of types, so defaulting will not occur. 
    3530 
    36 It is important to specify "unambiguous", because in the case of 
    37  
     31One problem of course is what does "unambiguous" mean?  In the case of 
    3832{{{ 
    3933default A (Int, String, ()) 
    4034default B (String, Int, ()) 
     35(A t, B t) => t 
     36}}} 
     37any of the three types would satisfy the rule that it is an instance of all the classes.  So what is the intepretation of "first" in the list? 
     38The only unambiguous interpretation of "first" valid type in both classes A and B would be (), to avoid making an arbitrary choice between Int and String. 
     39However, this is still far from clearcut.  Consider the following examples: 
     40{{{ 
     41default A (Int,String,()) 
     42default B (String,(),Int) 
     43(A t, B t) => t 
     44 
     45default C (Int, Double, String, ()) 
     46default D (Double,String,Int,()) 
     47(C t, D t) => t 
    4148}}} 
    4249 
    43 the only valid default for a type in both classes A and B should be ().  This avoids making an arbitrary choice based on 
    44 textual ordering of the default declaration clauses. 
    45  
    46 === pro === 
     50=== Pro === 
    4751 
    4852 * very useful in interactive interpreter 
     
    5054 * overcomes the Hat transformation problem 
    5155 
    52 === con === 
     56=== Con === 
    5357 
    5458 * can not exactly replicate behavior of existing defaulting mechanism, but can come close. 
    5559 * might hide errors, an optional warning on defaulting should be possible. 
     60 * not clear how to choose a single unambiguous member of more than one list of types 
    5661 
    5762 
    5863== Proposal 2 == 
    5964 
    60 Change the syntax of the defaulting clause from: 
     65Change default decls to (a) name the class being defaulted, and (b) permit only one default type per class, rather than a list. 
     66Possible syntax, by analogy with instance decls: 
    6167{{{ 
    62 topdecl  ->  default ( type_1 , ... , type_n ) 
     68topdecl  ->  default  tycls  type 
    6369}}} 
    64 to 
     70 
     71Semantically, which type is chosen is determined by the class context at the choice point (after context simplification).  That is, in 
    6572{{{ 
    66 topdecl  ->  default ( tycls_1 => type_1 , ... , tycls_n => type_n ) 
     73default C T 
     74(C a) => a 
    6775}}} 
    68 Semantically, 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. 
     76the type 'a', constrained by class 'C' but otherwise unresolved, is instantiated to the sole type 'T'. 
     77If 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  
     78than 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. 
     79 
     80Some examples: 
     81{{{ 
     82default Eq Integer 
     83default Fractional Float 
     84(Eq a, Fractional a) => a 
     85}}} 
     86After simplification, this becomes (Fractional a)=>a, because Eq is a superclass of Fractional.  Thus, there is a single class to be defaulted, and Float is chosen. 
     87{{{ 
     88default Ord Integer 
     89default Fractional Float 
     90(Ord a, Fractional a) => a 
     91}}} 
     92A static error, because Ord is not a superclass of Fractional, so the context does not simplify, and the default types disagree. 
     93{{{ 
     94  default Bounded Int 
     95  default Ord Int 
     96  (Ord a, Bounded a) => a 
     97}}} 
     98Default is Int, because even though the context does not simplify, the classes involved do agree on which default to choose. 
     99{{{ 
     100  default Bounded Int 
     101  default Ord Int 
     102  (Ord a, Bounded a, Show a) => a 
     103}}} 
     104Default is Int, same as above, except for the extra constraint Show a.  There is no default declared for Show, so the remaining context is used to make the choice. 
     105{{{ 
     106  (Show a, Read a) => a 
     107}}} 
     108A static error, because there are no defaults declared for any of the classes involved. 
    69109 
    70110The current Haskell'98 default-default behaviour can be specified as: