Changes between Version 17 and Version 18 of Records/NameSpacing


Ignore:
Timestamp:
Jan 9, 2012 8:16:59 AM (2 years ago)
Author:
GregWeber
Comment:

left-right solutions

Legend:

Unmodified
Added
Removed
Modified
  • Records/NameSpacing

    v17 v18  
    4646See below for how we resolve the type of this code. 
    4747 
    48 === Specifics on the dot === 
    49  
    50 This proposal requires the current Haskell function composition dot operator to have spaces (at least on the left side). No spaces around the dot are reserved for name-spacing: this use and the current module namespace use. The dot operator should bind as tightly as possible. 
     48=== Details on the dot === 
     49 
     50This proposal requires the current Haskell function composition dot operator to have spaces on both sides. No spaces around the dot are reserved for name-spacing: this use and the current module namespace use. No space to the right would be partial application (see [wiki:TypeDirectedNameResolution TDNR]. The dot operator should bind as tightly as possible. 
     51 
     52Given the dot's expanded use here, plus its common use in custom operators, it is possible to end up with dot-heavy code. 
     53 
     54{{{ 
     55quux (y . (foo>.<  bar).baz (f . g)) moo 
     56}}} 
     57 
     58It's not that easy to distinguish from 
     59 
     60{{{ 
     61quux (y . (foo>.<  bar) . baz (f . g)) moo 
     62}}} 
     63 
     64What then is the future of the dot if this proposal is accepted? I think the community need to chose among 2 alternatives: 
     65 
     661) discourage the use of dot in custom operators: `>.<` is bad, use a different character or none: `><` 
     672) discourage the use of dot for function composition - use a different operator for that task. Indeed, Frege users have the choice between `<~` or the proper unicode dot. 
    5168 
    5269 
     
    168185 
    169186 
    170 == Extending data name-spacing and dot syntax == 
    171  
    172 This is mostly just something interesting to contemplate. 
    173  
    174 Dot 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). I think it is a bad idea to attempt to attempt to extend the dot syntax to accomplish general function chaining through extending the dot syntax. However, it is consistent to extend the function name-spaced to a record data type concept to any data type (as it is in Frege), and use dot syntax for that. The dot (without spaces) *always* means tapping into a namespace (and simple type resolution). 
    175  
    176 Placing 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). With control over how the data namespace is exported (similar to controlling module namesapces), it is possible to create virtual record field setters and getters that can be accessed through dot syntax.  
    177  
    178 In this brave new world (see above where typeclass functions are also placed under the namespace of the data), there are few functions that *absolutlely must* be at the top level of a module. Although a library author might take attempt the approach of no top-level functions, obviously it will still be most convenient for users to define functions at the top level of modules rather than have to lift them into data structures. 
    179  
    180187== Partial application == 
    181188 
     
    183190`.a r == r.a` 
    184191 
     192 
    185193== Potential Downside: mixing of 2 styles of code == 
    186194 
     
    192200}}} 
    193201 
    194 It bothers some that the code does not look like the previous `b a r` - chiefly that the record is now in the middle. Is it possible we can have an equivalent of the dot that changes the ordering? `b a.@r` is possible, but requires an operator that binds to the right. 
     202It bothers some that the code does not look like the previous `b a r` - chiefly that the record is now in the middle. Chaining can make this perception even worse: `e d r.a.b.c` 
     203 
     204Is it possible we can have an equivalent of the dot that changes the ordering? `b a.@r` is possible, but requires an operator that binds tightly to the right. 
    195205 
    196206=== Partial Application === 
     
    199209 
    200210So if we have a function `f r = b r.a` then one can write it points-free: `b . .a` 
     211 
     212Our longer example from above: `e d . .c . .b . .a` 
     213 
     214At first glance it may look odd, but it is starting to grow on me. Also let us consider real use with longer names: 
     215{{{ 
     216echo delta . .charlie . .beta . .alpha 
     217}}} 
     218 
     219Is there are more convenient syntax for this? `b <.a` 
     220Note that a move to a different operator for function composition would make things much clearer: `b <~ .a`, where the unicode dot might be even nicer 
     221 
     222 
     223== Extending data name-spacing and dot syntax == 
     224 
     225This is mostly just something interesting to contemplate. 
     226 
     227Dot 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). I think it is a bad idea to attempt to attempt to extend the dot syntax to accomplish general function chaining through extending the dot syntax. However, it is consistent to extend the function name-spaced to a record data type concept to any data type (as it is in Frege), and use dot syntax for that. The dot (without spaces) *always* means tapping into a namespace (and simple type resolution). 
     228 
     229Placing 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). With control over how the data namespace is exported (similar to controlling module namesapces), it is possible to create virtual record field setters and getters that can be accessed through dot syntax. 
     230 
     231Both Frege and the DDC thesis take this approach. 
     232 
     233In this brave new world (see above where typeclass functions are also placed under the namespace of the data), there are few functions that *absolutlely must* be at the top level of a module. Although a library author might take attempt the approach of no top-level functions, obviously it will still be most convenient for users to define functions at the top level of modules rather than have to lift them into data structures. 
    201234