Changes between Version 14 and Version 15 of Records/DeclaredOverloadedRecordFields/COmpareSORF


Ignore:
Timestamp:
Feb 22, 2012 3:08:40 AM (3 years ago)
Author:
guest
Comment:

add speculative approach for higher-ranked types with constraints -- AntC

Legend:

Unmodified
Added
Removed
Modified
  • Records/DeclaredOverloadedRecordFields/COmpareSORF

    v14 v15  
    6262    So I can break the abstraction by updating a record/field I can't even `get` ?? Perhaps the desugarring should be:
    6363{{{
    64                 ===> set (undefined ::: "x") (True `asTypeOf` x (set (undefined ::: "x") True e)) e
    65                                                    --         ^^^ make sure the selector function is in scope
    66                                                    --        (and with the right types inferencable)
    67                                                    --         yeuch!! with bells on
     64                ===> set (undefined ::: "x")
     65                         (True `asTypeOf` x (set (undefined ::: "x") True e))
     66                                      -- ^^^ make sure the selector function is in scope (and with the right types inferencable)
     67                         e                                     --         yeuch!! hack with bells on
    6868}}}
    6969
     
    138138The prototype for this proposal originally included a method of updating Higher-ranked fields.
    139139
    140 It used an extra type function `SetTy`, with an extra type argument bound from the definition of method `set`:
     140It used an extra type function `SetTy`, with an extra forall'd type argument bound from the definition of method `set`:
    141141{{{
    142142    type family SetTy r fld t _a :: *        -- type of the argument to set into the record
     
    153153  So, I think that update of polymorphic fields remains problematic. "
    154154
     155 * Note that the "(ingenious)" and unscalable "hack" appears only in compiler-generated code.
     156
    155157 * We could scale up the hack by providing arbitrarily many forall-bound type variables to `SetTy` (`_a _b _c ...`). How many is more than enough?)
    156158
    157  * But we can't support constraints over the type variables. (Because constraints can't appear on the RHS of a type function instance. Perhaps this could be hacked using Constraints Kinds when they mature? They'd have to be declared on the method `set` within `Has`.)
     159 * But we can't support constraints over the type variables. (Because constraints can't appear on the RHS of a type function instance.) Perhaps this could be hacked using Constraints Kinds when they mature? They'd have to be declared on the method `set` within `Has`. Something like:
     160{{{
     161      type family SetTy r fld t _a _b _c :: *        -- type of the argument to set into the record
     162                                                     -- up to 3 forall'd typevars (could easily be more!)
     163          ...
     164      type family SetConstr r fld t _a _b _c :: Constraint  -- constraint(s) on the forall'd typevars
     165          ...
     166          set :: fld
     167              -> (forall _a _b _c. (SetConstr r fld t _a _b _c) => SetTy r fld t _a _b _c)
     168              -> r
     169              -> SetResult r fld t
     170          ...
     171}}}
    158172
    159  * Note that the "(ingenious)" and unscalable "hack" appears only in compiler-generated code.
     173    [I suspect this'll score no more merits for "ingenious", and a great many more demerits for "hack".]
     174
    160175
    161176Is it a requirement to be able to update polymorphic fields? Is it sufficient to be able to update other (monomorphic) fields in records that also contain poly fields?