Changes between Version 29 and Version 30 of PolymorphicComponents


Ignore:
Timestamp:
Apr 4, 2007 10:27:49 PM (8 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