Changes between Initial Version and Version 5 of Ticket #57

Jan 20, 2007 1:49:01 AM (8 years ago)


  • Ticket #57

    • Property Impact changed from normal to large
    • Property Topic changed from to Type Quantification
    • Property Adopt changed from maybe to probably yes
  • Ticket #57 – Description

    initial v5  
    11see PolymorphicComponents. 
     3see PolymorphicComponents. 
     5These are some rough and unfinished  notes about the details of 
     6adding polymorphic components to datatypes. 
     8== Notation == 
     10We need a notation to write the type schemes for polymorphic components. 
     11Hugs and GHC differ slightly in their choice of notation. 
     14=== Recognizing Schemes === 
     16We use 'forall' To indicate that a field in a constructor of a 
     17'data' or a 'newtype' declaration is polymorphic. 
     18In Hugs, 'forall' is implemented as a new keyword, while in GHC it 
     19is a "special" identifier that is treated differently in contexts 
     20that expect a type and in contexts that expect values.  For example, 
     21the following definitions is rejected by Hugs but accepted by GHC: 
     23f forall = forall 
     25PROPOSAL: adopt GHC's convention and treat 'forall' specially in 
     26types but allow it to be used in value declarations. 
     29=== Notation for Schemes === 
     32scheme    = 'forall' tvars '.' opt_ctxt type 
     34opt_ctxt  = context '=>' 
     35          | 
     38The non-terminal 'tvars' is a sequence of type variables that are 
     39separated by blank spaces.   We have a choice if we should allow 
     40empty quantifier sequences. 
     42==== Some static checking ==== 
     43Here are some differences between Hugs and GHC: 
     46  * does not allow empty quantifier lists 
     47  * requires that variables are mentioned in the body of a type 
     48  * permits predicates that do not mention any of the quantified variables 
     51  * allows empty quantifiers 
     52  * warns when quantified variables are not mentioned the body of a type 
     53  * disallows predicates that do not mention any of the quantified variables 
     55PROPOSAL: be liberal: 
     56  * allow empty quantifier lists 
     57  * allow variables that are not mentioned in the body of a type (but warn) 
     58  * allow predicates that do not mention quantified variables (but warn?) 
     61=== Strict Fields === 
     63The fields in 'data' constructors may be annotated with '!', indicating 
     64that they are strict.  Where should we place the '!' for a polymorphic field? 
     65It appears that this is not supported in Hugs (bug? I have not looked at 
     66the parser). In GHC, the '!' is placed before a schema and the schema has to 
     67be in parens (i.e. syntactically, a schema is just another 'type'). 
     71data T = C !(forall a. a -> a) Int 
     73PROPOSAL: GHC's choice seems reasonable. 
     75=== Labeled Fields, Infix Constructors === 
     77Again, we treat schemes as if they belong to category 'type'. 
     80data T = C { f1 :: forall a. a -> a, f2 :: Int } 
     81data T = (forall a. a -> a) :+: (forall x. x -> x) 
     83In the second example we need the parens to turn 'type' into 'atype'. 
     85== Constructors == 
     87Constructor that have polymorphic components cannot appear in the 
     88program without values for their polymorphic fields.  For example, 
     89consider the following declaration: 
     91data T a  = C Int (forall b. b -> a) a 
     93The constructor function 'C' should always be applied to at least 
     94two arguments because the second argument is the last polymorphic component 
     95of 'C'.  Here are some examples of how we can use 'C': 
     97ex1 :: a -> T a 
     98ex1 a = C 2 (const a)      -- ok. 
     100ex2 = C 2                  -- not ok, needs another argument. 
     103== Pattern matching == 
     105We do not allow nested patterns on fields that have polymorphic types. 
     106In other words, when we use a constructor with a polymorphic field 
     107as a pattern, we allow only variable and wild-card patterns in the 
     108positions corresponding to the polymorphic fields. 
     111newtype PolyList = C (forall a. [a]) 
     113polyNull (C []) = True    -- disallowed, nested pattern on a poly. field 
     114polyNull _      = False 
     116This is the behavior of both Hugs and GHC at present.