Changes between Version 15 and Version 16 of Records/SyntaxDirectedNameResolution


Ignore:
Timestamp:
Feb 28, 2012 4:50:06 AM (3 years ago)
Author:
elaforge
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • Records/SyntaxDirectedNameResolution

    v15 v16  
    210210 5. Module export list controls access over record fields as always.
    211211 6. Orthogonal to records: any function can be addressed.
     212 7. "Support" for polymorphic and higher-ranked fields, via existing record update syntax.  It's a cheat because it's also con #2, but I think it's a valid design to build on top of the existing syntax instead of replacing it.  Maybe it can be extended to support fancy stuff later, but meanwhile it solves the simple case while not precluding the complicated one.
    212213
    213214== cons ==
    214215
    215216 1. Still can't have two records with the same field name in the same module since it relies on modules for namespacing.
    216  2. Lenses can't handle updates that change the type, e.g. from `Rec a` to `Rec b`.  If the `set` function is `Lens rec field -> field -> rec -> rec` then you can't change the type of `rec`.  I'm sure if this is solvable without the set being builtin syntax, or a fancier lens implementation could admit `Lens rec1 rec2 field -> field -> rec1 -> rec2`.
     217 2. Lenses can't handle updates that change the type, e.g. from `Rec a` to `Rec b`.  If the `set` function is `Lens rec field -> field -> rec -> rec` then you can't change the type of `rec`.  I'm sure if this is solvable without the set being builtin syntax, or if a fancier lens implementation could admit `Lens rec1 rec2 field -> field -> rec1 -> rec2`.
    217218 3. It's another way to resolve a name to a different function body that's not typeclasses.  One way should be enough.  But typeclasses are fundamentally global.
    218219 4. The function to resolve must be monomorphic, so there is no "structural polymorphism" e.g. `getName :: (Has Name a) => a -> String`