On 25/01/2016, Imants Cekusins
could this not be better addressed by allowing explicit export / hiding of instances in a module?
That wouldn't enable such definitions as mine earlier, where the instance is defined in terms of other local terms.
does not type declaration inside function come at a performance cost?
Newtype declaration doesn't as they are elided at build time, and (at
least with GHC) the program would merely pass a class dictionary with
the locally-defined methods.
On 25/01/2016, Imants Cekusins
Currently module does not give control over instance export. Should this not be addressed first?
To my knowledge this would be a breach of consistency of instances:
one could so define terms with instances in conflict [0].
[0] http://stackoverflow.com/questions/8728596/explicitly-import-instances
On 25/01/2016, Yuras Shumovich
I'm not sure how your example works w.r.t. type variable scopes. Are you assuming ScopedTypeVariables? It will probably require explicit quantification to work:
ordNubBy :: forall a. (a -> a -> Ordering) -> [a] -> [a]
Yes, indeed, thanks for catching that ☺
In general, I see increasing demand for change scoping in haskell. For example see
...
Probably all of that should be addressed in a complex.
I think my proposal is orthogonal to all those as none of them seems to allow local instances defined in terms of other local terms.