Changes between Initial Version and Version 5 of Ticket #57

Jan 20, 2007 1:49:01 AM (9 years ago)


  • Ticket #57

    • Property Impact changed from normal to large
    • Property Topic changed from to Type Quantification
    • Property Adopt changed from maybe to probably yes
  • Ticket #57 – Description

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