Changes between Version 5 and Version 6 of Defaulting
- Timestamp:
- 11/21/06 02:49:23 (7 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Defaulting
v5 v6 4 4 [http://www.haskell.org/onlinereport/decls.html#sect4.3.4 Ambiguous Types, and Defaults for Overloaded Numeric Operations] in the Haskell 98 Report. 5 5 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. 6 Problems with the current defaulting rule: 8 7 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. 12 9 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. 15 11 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 17 14 * A default clause applies only within the module containing the declaration. Defaults can be neither 18 15 exported nor imported. Does anyone wish to propose import/export of defaults? … … 21 18 * 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. 22 19 23 == proposal 1 ==20 == Proposal 1 == 24 21 25 22 Allow defaulting clauses of the following form 26 27 23 {{{ 28 24 default <classname> (type1,type2,type3,...) 29 25 }}} 30 31 26 The defaulting rule will simply choose the first unambiguous type that satisfies all the constrained classes 32 27 listed in the default decls. … … 34 29 Classes without defaults will have the equivalent of an empty list of types, so defaulting will not occur. 35 30 36 It is important to specify "unambiguous", because in the case of 37 31 One problem of course is what does "unambiguous" mean? In the case of 38 32 {{{ 39 33 default A (Int, String, ()) 40 34 default B (String, Int, ()) 35 (A t, B t) => t 36 }}} 37 any 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? 38 The 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. 39 However, this is still far from clearcut. Consider the following examples: 40 {{{ 41 default A (Int,String,()) 42 default B (String,(),Int) 43 (A t, B t) => t 44 45 default C (Int, Double, String, ()) 46 default D (Double,String,Int,()) 47 (C t, D t) => t 41 48 }}} 42 49 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 === 47 51 48 52 * very useful in interactive interpreter … … 50 54 * overcomes the Hat transformation problem 51 55 52 === con ===56 === Con === 53 57 54 58 * can not exactly replicate behavior of existing defaulting mechanism, but can come close. 55 59 * 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 56 61 57 62 58 63 == Proposal 2 == 59 64 60 Change the syntax of the defaulting clause from: 65 Change default decls to (a) name the class being defaulted, and (b) permit only one default type per class, rather than a list. 66 Possible syntax, by analogy with instance decls: 61 67 {{{ 62 topdecl -> default ( type_1 , ... , type_n )68 topdecl -> default tycls type 63 69 }}} 64 to 70 71 Semantically, which type is chosen is determined by the class context at the choice point (after context simplification). That is, in 65 72 {{{ 66 topdecl -> default ( tycls_1 => type_1 , ... , tycls_n => type_n ) 73 default C T 74 (C a) => a 67 75 }}} 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. 76 the type 'a', constrained by class 'C' but otherwise unresolved, is instantiated to the sole type 'T'. 77 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 78 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. 79 80 Some examples: 81 {{{ 82 default Eq Integer 83 default Fractional Float 84 (Eq a, Fractional a) => a 85 }}} 86 After 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 {{{ 88 default Ord Integer 89 default Fractional Float 90 (Ord a, Fractional a) => a 91 }}} 92 A 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 }}} 98 Default 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 }}} 104 Default 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 }}} 108 A static error, because there are no defaults declared for any of the classes involved. 69 109 70 110 The current Haskell'98 default-default behaviour can be specified as:
