Changes between Version 6 and Version 7 of Records/NameSpacing


Ignore:
Timestamp:
Jan 8, 2012 1:17:33 AM (2 years ago)
Author:
GregWeber
Comment:

code syntax

Legend:

Unmodified
Added
Removed
Modified
  • Records/NameSpacing

    v6 v7  
    11See [wiki:Records] for the bigger picture. This is a proposal to solve the records name-spacing issue with simple name-spacing and simple type resolution.  
    22 
    3 This approach is an attempt to port the records solution in [http://code.google.com/p/frege/ 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 [http://code.google.com/p/frege/downloads/detail?name=Language-202.pdf Frege user manual] 
     3This approach is an attempt to port the records solution in [http://code.google.com/p/frege/ Frege], a haskell-like language on the JVM. Please read Sections 3.2 (primary expressions) and 4.2.1 (Algebraic Data type Declaration - Constructors with labeled fields) of the [http://code.google.com/p/frege/downloads/detail?name=Language-202.pdf Frege user manual] 
    44 
    55Many thanks to the Frege author, Ingo Wechsung for explaining his implementation and exploring this implementation territory for us. 
     
    7878This is the only real downside of the proposal. The Frege author says: 
    7979 
    80 I 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.) 
     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.) 
    8181 
    8282== Syntax for updates (in the Frege manual) == 
    8383 
    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 <-} 
     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 <-}` 
    8888 
    8989== Compatibility with existing records ==