| 2 | |
| 3 | see PolymorphicComponents. |
| 4 | |
| 5 | These are some rough and unfinished notes about the details of |
| 6 | adding polymorphic components to datatypes. |
| 7 | |
| 8 | == Notation == |
| 9 | |
| 10 | We need a notation to write the type schemes for polymorphic components. |
| 11 | Hugs and GHC differ slightly in their choice of notation. |
| 12 | |
| 13 | |
| 14 | === Recognizing Schemes === |
| 15 | |
| 16 | We use 'forall' To indicate that a field in a constructor of a |
| 17 | 'data' or a 'newtype' declaration is polymorphic. |
| 18 | In Hugs, 'forall' is implemented as a new keyword, while in GHC it |
| 19 | is a "special" identifier that is treated differently in contexts |
| 20 | that expect a type and in contexts that expect values. For example, |
| 21 | the following definitions is rejected by Hugs but accepted by GHC: |
| 22 | {{{ |
| 23 | f forall = forall |
| 24 | }}} |
| 25 | PROPOSAL: adopt GHC's convention and treat 'forall' specially in |
| 26 | types but allow it to be used in value declarations. |
| 27 | |
| 28 | |
| 29 | === Notation for Schemes === |
| 30 | |
| 31 | {{{ |
| 32 | scheme = 'forall' tvars '.' opt_ctxt type |
| 33 | |
| 34 | opt_ctxt = context '=>' |
| 35 | | |
| 36 | }}} |
| 37 | |
| 38 | The non-terminal 'tvars' is a sequence of type variables that are |
| 39 | separated by blank spaces. We have a choice if we should allow |
| 40 | empty quantifier sequences. |
| 41 | |
| 42 | ==== Some static checking ==== |
| 43 | Here are some differences between Hugs and GHC: |
| 44 | |
| 45 | Hugs: |
| 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 |
| 49 | |
| 50 | GHC: |
| 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 |
| 54 | |
| 55 | PROPOSAL: 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?) |
| 59 | |
| 60 | |
| 61 | === Strict Fields === |
| 62 | |
| 63 | The fields in 'data' constructors may be annotated with '!', indicating |
| 64 | that they are strict. Where should we place the '!' for a polymorphic field? |
| 65 | It appears that this is not supported in Hugs (bug? I have not looked at |
| 66 | the parser). In GHC, the '!' is placed before a schema and the schema has to |
| 67 | be in parens (i.e. syntactically, a schema is just another 'type'). |
| 68 | |
| 69 | Example: |
| 70 | {{{ |
| 71 | data T = C !(forall a. a -> a) Int |
| 72 | }}} |
| 73 | PROPOSAL: GHC's choice seems reasonable. |
| 74 | |
| 75 | === Labeled Fields, Infix Constructors === |
| 76 | |
| 77 | Again, we treat schemes as if they belong to category 'type'. |
| 78 | Examples: |
| 79 | {{{ |
| 80 | data T = C { f1 :: forall a. a -> a, f2 :: Int } |
| 81 | data T = (forall a. a -> a) :+: (forall x. x -> x) |
| 82 | }}} |
| 83 | In the second example we need the parens to turn 'type' into 'atype'. |
| 84 | |
| 85 | == Constructors == |
| 86 | |
| 87 | Constructor that have polymorphic components cannot appear in the |
| 88 | program without values for their polymorphic fields. For example, |
| 89 | consider the following declaration: |
| 90 | {{{ |
| 91 | data T a = C Int (forall b. b -> a) a |
| 92 | }}} |
| 93 | The constructor function 'C' should always be applied to at least |
| 94 | two arguments because the second argument is the last polymorphic component |
| 95 | of 'C'. Here are some examples of how we can use 'C': |
| 96 | {{{ |
| 97 | ex1 :: a -> T a |
| 98 | ex1 a = C 2 (const a) -- ok. |
| 99 | |
| 100 | ex2 = C 2 -- not ok, needs another argument. |
| 101 | }}} |
| 102 | |
| 103 | == Pattern matching == |
| 104 | |
| 105 | We do not allow nested patterns on fields that have polymorphic types. |
| 106 | In other words, when we use a constructor with a polymorphic field |
| 107 | as a pattern, we allow only variable and wild-card patterns in the |
| 108 | positions corresponding to the polymorphic fields. |
| 109 | Example: |
| 110 | {{{ |
| 111 | newtype PolyList = C (forall a. [a]) |
| 112 | |
| 113 | polyNull (C []) = True -- disallowed, nested pattern on a poly. field |
| 114 | polyNull _ = False |
| 115 | }}} |
| 116 | This is the behavior of both Hugs and GHC at present. |