Changes between Version 29 and Version 30 of PolymorphicComponents

Timestamp:

04/04/07 15:27:49 (6 years ago)

Author:

diatchki

Comment:

--

PolymorphicComponents

@@ -101 +101 @@
 
 === Labeled fields ===
+(Section 3.15?)
 
 Type of the selector functions:
@@ -114 +115 @@
 
 === Constructors ===
+(Section 4.2.1)
 
 Constructors that have polymorphic components cannot appear in the program
@@ -135 +137 @@
 The values for the polymorphic components should have type schemes
 that are at least as polymorphic as what is declared in the datatype.
-This is checked is similar to the check that is performed when an
-expression has an explicit type signature.
+This is similar to the check that is performed when an expression
+has an explicit type signature.
 
-TODO:
+=== Patterns ===
+
+We do not allow nested patterns on fields that have polymorphic types.
+In other words, when we use a constructor with a polymorphic field as a pattern,
+we allow only variable and wild-card patterns in the positions corresponding
+to the polymorphic fields.
+
+Discussion:  We could lift this restriction but the resulting behavior
+may be more confusing than useful.  Consider the following example:
+{{{
+data S     = C (forall a. [a -> a])
+
+test1 (C x) 
+  | null x    = ('b', False)
+  | otherwise = (f 'a', f True)
+    where f = head x
+
+test2 (C [])      = ('b', False)
+test2 (C (f : _)) = (f 'a', f True)
+}}}
+We may expect that these two definitions are equivalent
+but, in fact, the first one is accepted while the
+second one is rejected if we perform the usual
+translation of patterns.  To see what goes wrong,
+consider how we desugar patterns:
+{{{
+test2 (C x) = case x of
+                []  -> ('b',False)
+                f:_ -> (f 'a', f True)
+}}}
+The use of {{{x}}} in the '''case''' statement instantiates
+it to a particular type, which makes {{{f}}} monomorphic
+and so we cannot instantiate it to different types.
+An alternative might be to perform a generalization after
+we pattern match on a polymorphic field but it is not clear
+if this extra complexity is useful.  
+
+
+== TODO  ==
  1. lots of english text in algebreic datatype declartions
- 1. english text in Labelled fields - give an example of fields with polymorphic types, or do this in section 3?
  1. anything in "kind inference"?
  1. ''note'' you can name polymorphic components (see design choice above)
-   1. when you match on ''x'' it instantiates the forall to a monomorphic type as below:
-{{{
-data S    = C (forall a. [a])
-
-f (C x)   = (show (x::[Int]), show (x::String))
-           
--- f (C []) = ("[]","\"\"")
-}}}
-   1. this is not allowed: (see open issue above, iavor thinks GHC tried this and it was really tricky)
-{{{
-f (C []) = True
-}}}
-   1. desugaring...
-{{{
-f (C []) = e1 -- illegal
-}}}
-  would desugar to
-{{{
-f x = case x of
-       C [] -> e 1 -- illegal
-       _ -> error ...
-}}}
-  would desugar to 
-{{{
-case x of
- C y -> case y of -- NOT illegal
-         [] -> e1
-         _ -> error...
- _ -> error...
-
-}}}
-  which is a little funny.
- 1. where is explanation of type checking...
- 1. where to put the bangs in strict polymorphic fields, hugs and GHC differ - can't figure it out in Hugs