Changes between Version 33 and Version 34 of Records/NameSpacing


Ignore:
Timestamp:
Jan 18, 2012 3:52:24 AM (4 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