Changes between Version 29 and Version 30 of PolymorphicComponents


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

--

Legend:

Unmodified
Added
Removed
Modified
  • PolymorphicComponents

    v29 v30  
    101101 
    102102=== Labeled fields === 
     103(Section 3.15?) 
    103104 
    104105Type of the selector functions: 
     
    114115 
    115116=== Constructors === 
     117(Section 4.2.1) 
    116118 
    117119Constructors that have polymorphic components cannot appear in the program 
     
    135137The values for the polymorphic components should have type schemes 
    136138that are at least as polymorphic as what is declared in the datatype. 
    137 This is checked is similar to the check that is performed when an 
    138 expression has an explicit type signature. 
     139This is similar to the check that is performed when an expression 
     140has an explicit type signature. 
    139141 
    140 TODO: 
     142=== Patterns === 
     143 
     144We do not allow nested patterns on fields that have polymorphic types. 
     145In other words, when we use a constructor with a polymorphic field as a pattern, 
     146we allow only variable and wild-card patterns in the positions corresponding 
     147to the polymorphic fields. 
     148 
     149Discussion:  We could lift this restriction but the resulting behavior 
     150may be more confusing than useful.  Consider the following example: 
     151{{{ 
     152data S     = C (forall a. [a -> a]) 
     153 
     154test1 (C x)  
     155  | null x    = ('b', False) 
     156  | otherwise = (f 'a', f True) 
     157    where f = head x 
     158 
     159test2 (C [])      = ('b', False) 
     160test2 (C (f : _)) = (f 'a', f True) 
     161}}} 
     162We may expect that these two definitions are equivalent 
     163but, in fact, the first one is accepted while the 
     164second one is rejected if we perform the usual 
     165translation of patterns.  To see what goes wrong, 
     166consider how we desugar patterns: 
     167{{{ 
     168test2 (C x) = case x of 
     169                []  -> ('b',False) 
     170                f:_ -> (f 'a', f True) 
     171}}} 
     172The use of {{{x}}} in the '''case''' statement instantiates 
     173it to a particular type, which makes {{{f}}} monomorphic 
     174and so we cannot instantiate it to different types. 
     175An alternative might be to perform a generalization after 
     176we pattern match on a polymorphic field but it is not clear 
     177if this extra complexity is useful.   
     178 
     179 
     180== TODO  == 
    141181 1. lots of english text in algebreic datatype declartions 
    142  1. english text in Labelled fields - give an example of fields with polymorphic types, or do this in section 3? 
    143182 1. anything in "kind inference"? 
    144183 1. ''note'' you can name polymorphic components (see design choice above) 
    145    1. when you match on ''x'' it instantiates the forall to a monomorphic type as below: 
    146 {{{ 
    147 data S    = C (forall a. [a]) 
    148  
    149 f (C x)   = (show (x::[Int]), show (x::String)) 
    150             
    151 -- f (C []) = ("[]","\"\"") 
    152 }}} 
    153    1. this is not allowed: (see open issue above, iavor thinks GHC tried this and it was really tricky) 
    154 {{{ 
    155 f (C []) = True 
    156 }}} 
    157    1. desugaring... 
    158 {{{ 
    159 f (C []) = e1 -- illegal 
    160 }}} 
    161   would desugar to 
    162 {{{ 
    163 f x = case x of 
    164        C [] -> e 1 -- illegal 
    165        _ -> error ... 
    166 }}} 
    167   would desugar to  
    168 {{{ 
    169 case x of 
    170  C y -> case y of -- NOT illegal 
    171          [] -> e1 
    172          _ -> error... 
    173  _ -> error... 
    174  
    175 }}} 
    176   which is a little funny. 
    177  1. where is explanation of type checking... 
    178  1. where to put the bangs in strict polymorphic fields, hugs and GHC differ - can't figure it out in Hugs