#8297: Allow implicit parameters to take a default value ----------------------------------------------+---------------------------- Reporter: schyler | Owner: Type: feature request | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Moderate (less than a day) | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: ----------------------------------------------+---------------------------- -XImplicitParams is not that useful except as a type hole. I had an idea where they could be adjusted to be really useful. Consider a function `primes` which uses a wheel sieve. {{{ -- primes: takes a size of the wheel to use, returns a lazy list of primes primes :: Int -> [Int] }}} Your average Joe may not be concerned about the technical details of this function. Why should he have to bother giving a wheel size? The function documentation might say `6` is a good value, but what if some research is done in the future and the library maintainer changes it, later deciding `7` is better? Joe wants to trust the library maintainer, but doesn't want to be burdened by maintaining this arbitrary constant in his code, nor does he like having to pass another parameter to primes. The type of `primes` could be implemented using an implicit parameter like this: {{{ primes -- returns an infinite list of primes primes :: (?wheelSize :: Int) -> [Int] }}} Joe still has to provide a wheelSize however, and now it's even more verbose than before. Wouldn't it be nice if the person who wrote the function could define a default value for `wheelSize`? Joe could use `primes` by itself in his code, whereas Bob, who runs his code on a very powerful server, could tune the performance of his sieve manually by explicitly using `primes where wheelSize = 100`. My suggestion is to develop a syntax which allows functions to define ''default'' values for their implicit parameters. I'm sure the community would have some fun coming up with creative uses for this in their libraries! As an extreme situation, consider the below example; {{{ -- takes a foo, bar, alpha, beta, gamma and epsilon for performance tuning. ouch. aVeryComplexSieveEx :: Int -> Int -> Int -> Int -> Int ... -> r -- f $ aVeryComplexSieveEx 1 2 3 4 ... aVeryComplexSieveEx :: SomeCompulsaryRecordConstructor -> Int -> r -- f $ aVeryComplexSieveEx (SomeCompulsaryRecordConstructor { ... }) 3 }}} vs {{{ aVeryComplexSieveEx :: (?foo :: Int, ?bar :: Int, ?alpha :: Int, ?beta :: Int, ?gamma :: Int) -> Int -> r -- f $ let ?alpha = 1337 in aVeryComplexSieveEx 3 }}} As you can see it would be beneficial for libraries to expose *optional* ways for users to tune internal values in this manner, without having to pass record constructors with many options or make new functions with tiresome numbers of parameters. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8297 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler