Local definitions in the class instances

Boris Lykah lykahb at gmail.com
Sun Jan 30 11:41:02 CET 2011

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 <nbowler at 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/)


More information about the Haskell-prime mailing list