Changes between Version 27 and Version 28 of Records/NameSpacing


Ignore:
Timestamp:
Jan 11, 2012 11:37:58 AM (2 years ago)
Author:
GregWeber
Comment:

fix wiki syntax

Legend:

Unmodified
Added
Removed
Modified
  • Records/NameSpacing

    v27 v28  
    209209 
    210210 
    211 === Dealing with dot-heavy code === 
    212  
    213 ==== Identifying the difference between a name-space dot and function composition ==== 
     211== Dealing with dot-heavy code == 
     212 
     213=== Identifying the difference between a name-space dot and function composition === 
    214214 
    215215Given the dot's expanded use here, plus its common use in custom operators, it is possible to end up with dot-heavy code. 
     
    234234Discouraging the use of the dot in custom operators makes the example code only slightly better. With the second we now have: 
    235235 
    236 {{ 
     236{{{ 
    237237quux (y <~ (foo>.<  bar).baz (f <~ g)) moo 
    238238}}} 
     
    246246If you are disgusted by `<~` than you can use the very pretty unicode dot. 
    247247 
    248 ==== Downside: mixing of 2 styles of code ==== 
     248=== Downside: mixing of 2 styles of code === 
    249249 
    250250{{{ 
     
    257257It 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` 
    258258 
    259 ===== Solution: Partial Application ===== 
     259==== Solution: Partial Application ==== 
    260260 
    261261Partial application provides a potential solution: `b . .a $ r` 
     
    276276 
    277277 
    278 ===== Solution: Field selector to the left of the record ===== 
     278==== Solution: Field selector to the left of the record ==== 
    279279 
    280280We could have an equivalent of the dot where the field is to the left of the record: `b a@r` 
     
    310310Both Frege and the DDC thesis take this approach. 
    311311 
    312 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 structure namespaces. 
     312In 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 structure namespaces.