Changes between Version 28 and Version 29 of PolymorphicComponents


Ignore:
Timestamp:
Apr 4, 2007 10:00:10 PM (7 years ago)
Author:
diatchki
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • PolymorphicComponents

    v28 v29  
    5959= Report TODO List = 
    6060List of items that need to change in the [http://darcs.haskell.org/haskell-prime-report/report/haskell-prime-draft.html draft report]. 
    61  1. Introduce a new ''special identifier'', '''forall'''.  This identifier has a special interpretation in types and type schemes (i.e., it is ''not'' a type variable). 
    62     However, '''forall''' can still be used as an ordinary variable in expressions. 
    63  2. Syntax for writing type schemes: 
    64     (TODO: check for ambiguities with happy.) 
     61 
     62== Syntax == 
     63Introduce a new ''special identifier'', '''forall'''.  This identifier has a special interpretation in types and type schemes (i.e., it is ''not'' a type variable). 
     64However, '''forall''' can still be used as an ordinary variable in expressions. 
     65 
     66Syntax for writing type schemes: 
    6567{{{ 
    6668poly     -> 'forall' tvar_1 ... tyvar_n '.' opt_ctxt type    (n > 0) 
     
    7173bscheme  -> '(' poly ')' | btype 
    7274}}} 
    73  NOTE: Schemes should not contain quantified variables that are not mentioned 
    74        in the scheme body because this probably indicates a programmer error. 
    75  3. Syntax for '''data''' and '''newtype''' declarations  
     75NOTE: Schemes should not contain quantified variables that are not mentioned in the scheme body because this probably indicates a programmer error. 
     76 
     77Syntax for '''data''' and '''newtype''' declarations  
    7678{{{ 
    7779-- Section 4.2.1 
     
    8991          | con { var :: scheme } 
    9092}}} 
    91  NOTE: The grammar in the Haskell 98 report contains a minor bug that seems 
    92  to allow erroneous data declarations like the following: 
     93NOTE: The grammar in the Haskell 98 report contains a minor bug that seems 
     94to allow erroneous data declarations like the following: 
    9395{{{ 
    9496data T = C ! 
    9597}}} 
    96  For this reason I introduced the ''con_field'' productions. 
    97  4. Labeled fields.   
    98    1. Type of the selector functions: 
     98For this reason I introduced the ''con_field'' productions. 
     99 
     100== Working with datatypes == 
     101 
     102=== Labeled fields === 
     103 
     104Type of the selector functions: 
    99105{{{ 
    100106data T a = C { x :: forall b. ctxt  => type } 
    101107x :: ctxt => T a -> type 
    102108}}} 
    103    2. If different constructors of the same datatype contain the same label, 
    104     then the      corresponding schemes should be equal up to renaming of the 
    105     quantified variables. 
    106109 
     110If different constructors of the same datatype contain the same label, 
     111then the corresponding schemes should be equal up to renaming of the 
     112quantified variables.  This ensures that we can give a reasonable type 
     113for the selector functions. 
     114 
     115=== Constructors === 
     116 
     117Constructors that have polymorphic components cannot appear in the program 
     118without values for their polymorphic fields. For example, 
     119consider the following declaration: 
     120{{{ 
     121data T a  = C Int (forall b. b -> a) a 
     122}}} 
     123The constructor function 'C' cannot be used with less then two arguments 
     124because the second argument is the last polymorphic component of 'C'. 
     125Here are some examples that illustrate what we can and cannot do with 'C': 
     126{{{ 
     127ex1 :: a -> T a 
     128ex1 a = C 2 (const a)      -- ok. 
     129 
     130ex2 = C 2                  -- not ok, needs another argument. 
     131}}} 
     132This restriction ensures that all expressions in the program have 
     133ordinary Hindley-Milner types. 
     134 
     135The values for the polymorphic components should have type schemes 
     136that are at least as polymorphic as what is declared in the datatype. 
     137This is checked is similar to the check that is performed when an 
     138expression has an explicit type signature. 
    107139 
    108140TODO: 
     
    110142 1. english text in Labelled fields - give an example of fields with polymorphic types, or do this in section 3? 
    111143 1. anything in "kind inference"? 
    112  1. ''note for'': for field labels, when you have the same label in different constructors, it's permitted as long as the type is the same; anything here to describe the syntactic checking that occurs to determine whether these types are the same?  "Syntactic up-to alpha-renaming." Might be unintuative as this is rejected by GHC and Hugs: 
    113 {{{ 
    114 data T  = C1 { x :: forall a. (Show a,Eq a) => a -> a } 
    115         | C2 { x :: forall a. (Eq a,Show a) => a -> a }  
    116 }}} 
    117144 1. ''note'' you can name polymorphic components (see design choice above) 
    118145   1. when you match on ''x'' it instantiates the forall to a monomorphic type as below: