Changes between Version 5 and Version 6 of Defaulting


Ignore:
Timestamp:
Nov 21, 2006 10:49:23 AM (9 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: