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?