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
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