Changes between Version 33 and Version 34 of Records/NameSpacing


Ignore:
Timestamp:
Jan 18, 2012 3:52:24 AM (2 years ago)
Author:
GregWeber
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • Records/NameSpacing

    v33 v34  
    192192 
    193193                                                                                 
    194 == Details on the dot == 
    195  
    196 This 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  
    197 [http://hackage.haskell.org/trac/haskell-prime/wiki/TypeDirectedNameResolution TDNR]. The dot operator should bind as tightly as possible. 
    198  
    199 === Partial application === 
    200  
    201 see [http://hackage.haskell.org/trac/haskell-prime/wiki/TypeDirectedNameResolution TDNR] syntax discusion for an explanation. 
    202 {{{ 
    203 (.a) r == r.a 
    204 }}} 
    205  
    206 .x (no space after the dot), for any identifier x, is a postfix operator that binds more tightly than function application, so that parentheses are not usually required. 
    207 {{{ 
    208 .a r == r.a 
    209 }}} 
    210  
    211 When there are multiple operators, they chain left to right 
    212 {{{ 
    213 (r.a.b.c) == (.c $ .b $ .a r) 
    214 }}} 
    215  
    216 See below for how partial application can allow for different code styles. 
    217  
    218 Question: does this now hold? 
    219 {{{ 
    220 r.a == r.(Record.a) == r.Record.a 
    221 }}} 
    222  
    223  
    224  
    225 == Dealing with dot-heavy code == 
    226  
    227 === Identifying the difference between a name-space dot and function composition === 
    228  
    229 Given the dot's expanded use here, plus its common use in custom operators, it is possible to end up with dot-heavy code. 
    230  
    231 {{{ 
    232 quux (y . (foo>.<  bar).baz (f . g)) moo 
    233 }}} 
    234  
    235 It's not that easy to distinguish from 
    236  
    237 {{{ 
    238 quux (y . (foo>.<  bar) . baz (f . g)) moo 
    239 }}} 
    240  
    241 What then is the future of the dot if this proposal is accepted? The community needs to consider ways to reduce the dot: 
    242  
    243 1) discourage the use of dot in custom operators: `>.<` could be discouraged, use a different character or none: `><` 
    244 In most cases the dot in custom operators has little to no inherent meaning. Instead it is just the character available for custom operators that takes up the least real-estate. This makes it the best choice for implementing a custom operator modeled after an existing Haskell operator: `.==` or `.<` is normably preferable to `@==` and `@<`. 
    245  
    246 2) 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. 
    247 Haskell also has `Control.Category.<<<` 
    248  
    249 Discouraging the use of the dot in custom operators makes the example code only slightly better. With using a different operator we now have: 
    250  
    251 {{{ 
    252 quux (y <~ (foo>.<  bar).baz (f <~ g)) moo 
    253 }}} 
    254  
    255 Very easy to distinguish from 
    256  
    257 {{{ 
    258 quux (y <~ (foo>.<  bar) <~ baz (f <~ g)) moo 
    259 }}} 
    260  
    261 If you are disgusted by `<~` than you can use the very pretty unicode dot. Or we can stick with the category operator `<<<` instead of `<~`: 
    262  
    263 {{{ 
    264 quux (y <<< (foo>.<  bar).baz (f <<< g)) moo 
    265 }}} 
    266  
    267  
    268 === Downside: mixing of 2 styles of code === 
    269  
    270 {{{ 
    271 data Record = Record { a::String } 
    272 b :: Record -> String 
    273  
    274 let r = Record "a" in b r.a  
    275 }}} 
    276  
    277 It bothers some that the code does not read strictly left to right as in: `b . a . r`. Chaining can make this even worse: `(e . d) r.a.b.c` 
    278  
    279 ==== Solution: Partial Application ==== 
    280  
    281 Partial application provides a potential solution: `b . .a $ r` 
    282  
    283 So if we have a function `f r = b r.a` then one can write it points-free: `b . .a` 
    284  
    285 Our longer example from above: `e . d . .c . .b . .a` 
    286  
    287 Let us consider real use with longer names: 
    288 {{{ 
    289 echo . delta . .charlie . .beta . .alpha 
    290 }}} 
    291  
    292 Note that a move to a different operator for function composition (see discussion above) would make things much nicer: 
    293 {{{ 
    294 echo <~ delta <~ .charlie <~ .beta <~ .alpha 
    295 }}} 
    296  
    297  
    298 ==== Solution: Field selector to the left of the record ==== 
    299  
    300 We could have an equivalent of the dot where the field is to the left of the record: `b a@r` 
    301 Could this also be used in a partial syntax? 
    302  
    303 {{{ 
    304 echo . delta . charlie@ . beta@ . alpha@ 
    305 }}} 
    306  
    307 Can this be shortened to: 
    308  
    309 {{{ 
    310 echo . delta . charlie@beta@alpha@ 
    311 }}} 
    312  
    313 Or would this syntax alway need to be applied? 
    314  
    315 {{{ 
    316 echo . delta $ charlie@beta@alpha@r 
    317 }}} 
     194 
    318195 
    319196