[GHC] #11349: [TypeApplications] Create Proxy-free alternatives of functions in base

[GHC]

#11349: [TypeApplications] Create Proxy-free alternatives of functions in base
-------------------------------------+-------------------------------------
        Reporter:  Iceland_jack      |                Owner:
            Type:  feature request   |               Status:  new
        Priority:  normal            |            Milestone:
       Component:  Core Libraries    |              Version:  7.10.3
      Resolution:                    |             Keywords:
                                     |  TypeApplications
Operating System:  Other             |         Architecture:
                                     |  Unknown/Multiple
 Type of failure:  None/Unknown      |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by rwbarton):

 Replying to [comment:4 Iceland_jack]:
 > For the '''''T'''angent '''o'''f '''t'''he '''D'''ay'' ('''''a'''s
 '''a''' '''S'''ervice'') (''TotD''(''aaS'')), how should the inclusion of
 Natural in base influence functions and other libraries?

 Off-topic, but...

 > Functions like `length`, `take`, `drop`, `splitAt`, `replicate` scream
 for natural numbers as their arguments: Their types are of course well
 established, `Int` is also fixed- while `Natural` is arbitrary-precision.
 Is `Word` suitable? Maybe not worth it.

 Very unsuitable as long as subtraction on Word has wrap-around behavior
 rather than erroring. You would fail to catch a lot of programming errors
 that way, when passing wrapped values to functions that used to check
 whether their argument was negative, and in other cases you would silently
 change program behavior, when using functions that used to treat negative
 values as 0. See http://www.wabbo.org/blog/2014/22aug_on_bananas.html for
 a related example from Rust.

 Word is basically useless as an "efficient small-ish Natural" for this
 reason, and only makes sense when you specifically want the machine-
 specific wrap-around behavior, or when doing bit manipulation only. (And
 yes, Int can overflow too, making it somewhat less effective as an
 "efficient small-ish Integer", but overflowing an Int computation requires
 large inputs (which are often impossible to provide to the program in
 practice), while a Word computation can be overflowed with very small
 inputs.)

--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11349#comment:5>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler