Changes between Version 4 and Version 5 of Records/NameSpacing

Jan 8, 2012 1:10:43 AM (3 years ago)

fill out proposal


  • Records/NameSpacing

    v4 v5  
    33This approach is an attempt to port the records solution in [ Frege], a haskell-like language on the JVM. See Sections 3.2 (primary expressions) and 4.2.1 (Algebraic Data type Declaration - Constructors with labeled fields) of the [ Frege user manual] 
    5 === Better name spacing === 
     5Many thanks to the Frege author, Ingo Wechsung for explaining his implementation and exploring this implementation territory for us. 
     7== Better name spacing == 
    79In Haskell, you can look at an occurrence of any identifier `f` or `M.f` and decide where it is bound without thinking about types at all.  Broadly speaking it works like this: 
    24 === Simple type resolution === 
     26== Simple type resolution == 
    2628Frege has a detailed explanation of the semantics of its record implementation, and the language is *very* similar to Haskell. After reading the Frege manual sections, one is still left wondering: how does Frege implement type resolution for its TDNR syntax. The answer is fairly simple: overloaded record fields are not allowed. So you can't write code that works against multiple record types. Please see the comparison with Overloading in [wiki Records], which includes a discussion of the relative merits. Back to simple type resolution. From the Frege Author: 
    7173 * when the type checker sees `x.f` and knows that `x::R` 
    7274 * In code that lives itself in the namespace `R`, here even an unqualified `f` will resolve to `R.f` (unless, of course, if there is a local binding for `f`) 
     76=== Increased need for type annotation === 
     78This is the only real downside of the proposal. The Frege author says: 
     80I estimate that in 2/3 of all cases one does not need to write (T.e x) in sparsely type annotated code, despite the fact that the frege type checker has a left to right bias and does not yet attempt to find the type of x in the code that "follows" the x.e construct (after let unrolling etc.) I think one could do better and guarantee that, if the type of x is inferrable at all, then so will be x.e (Still, it must be more than just a type variable.) 
     82== Syntax for updates (in the Frege manual) == 
     84  * the function that updates field x of data type T is T.{x=} 
     85  * the function that sets field x in a T to 42 is T.{x=42} 
     86  * If a::T then a.{x=} and a.{x=42} are valid 
     87  * the function that changes field x of a T by applying some function to it is T.{x <-} 
     89== Compatibility with existing records == 
     91Seems like it should be OK to use old records in the new system. 
     92There is a chance for deeper though on this issue. 
     95== Extending data name-spacing and TDNR syntax == 
     97This is mostly just something interesting to contemplate. 
     98TDNR syntax does not have to be limited to records (although it probably should be for the initial implementation until this new record system is vetted). 
     99Placing functions within a data name-space can make for nicer data-structure oriented code where the intent is clearer. It can help to achieve the data-oriented goal of OO without the entanglement of state. Is it possible to create "virtual" record field setters and getters that can be accessed through TDNR syntax and to control exactly what parts of the data namespace are accessible?