Changes between Version 42 and Version 43 of Records/OverloadedRecordFields


Ignore:
Timestamp:
Sep 12, 2016 7:37:21 PM (14 months ago)
Author:
adamgundry
Comment:

remove outdated discussion

Legend:

Unmodified
Added
Removed
Modified
  • Records/OverloadedRecordFields

    v42 v43  
    1212
    1313Content previously on this page has been moved to the [wiki:Records/OverloadedRecordFields/SORF SORF] page.
    14 
    15 == Discussion ==
    16 
    17 ''Lennart'': I've implemented 2&3 in the Mu compiler, and I'll add some comments about it.
    18 
    19 ''Lennart'': The MagicClasses proposal is fundamentally broken, because it breaks abstraction.
    20 
    21 If we have a data type `R` with a field `foo` of type `T`, then we generate `instance HasField "foo" R T`.
    22 Since instances are silently exported and imported it means that this instance is now available in every module that somehow depends on the defining module.  This means that the `foo` field of `R` is now accessible everywhere.  There is no way to limit the scope of `foo` anymore.  This is really terrible.  Any record proposal that no longer allows abstract data types to be defined is broken.
    23 
    24 ''Adam'': I don't think so. We will only solve a `HasField` constraint automatically in modules that have the field in scope, and thus we can retain the same abstraction rules as normal Haskell. This is just like `Coercible`. We don't really generate and export instances, rather there is special behaviour in the constraint solver. See [wiki:Records/OverloadedRecordFields/MagicClasses#Representationhiding discussion on representation hiding] (now updated to the latest design).
    2514
    2615== Issues ==