Thanks for pointing at the problems with new and default class functions. But if we distinct the local and class functions I see no other problems.
Iavor, your local/in suggestion is very interesting. I would like to see local declarations in the Haskell standard some day. However, it affects much more than class instances and needs a lot of discussion. It can conflict with let/in construct. In the example with export I would rather use > module M hiding (not exported functions) where It is more coherent with the import syntax, though local definitions are more generic. I know GHC internals a little and would like to learn more. When I finish my diploma paper, I can try to implement some extensions which the community considers useful. On Thu, Jan 27, 2011 at 8:02 PM, Nick Bowler <nbow...@elliptictech.com> wrote: > On 2011-01-27 13:07 +0200, Boris Lykah wrote: >> I think it would be convenient to allow adding variables and >> functions, which are not members of the class, to a class instance so >> that they are visible only in the instance scope. It will help if the >> same functions are used by several class functions. >> >> Example: >> When implementing Num class for my datatype, I found that I routinely >> do unwrapping in each operator definition. I extracted it into >> functions, but as they are used only in instance definition, I want to >> put them there and restrict them to that scope. It would be neater >> than leaving them in the global scope or copypasting into each >> operator. > > One problem with this proposal is that it hurts modularity, as there is > no distinction in the instance declarations between the definitions of > "instance-local" functions and those of class methods. > > This means that you cannot add new methods to an existing class > (together with a default implementation in terms of the existing > methods) without potentially breaking the existing instances. > > -- > Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/) > -- Regards, Boris _______________________________________________ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
