[Haskell-cafe] programming style...and type classes...

[Nicholls, Mark]

>> >My rule of thumb is that if there is one obvious instance (or none)
>> >for every given type, then your abstraction is a good candidate for a
>> >typeclass; if multiple instances make sense, then it's a judgment
>> >call; and if many instances could arbitrarily make sense or not
>> >depending on the usage / circumstances, then it's probably not a good
>candidate for a typeclass.
>>
>> OK, that’s a bit more prescriptive...so if many instances make sense (Ord a)
>then what?
>>
>> Seems like Ord is a "bad" typeclass?...it should really be a dictionary data
>type? And then you simply define which order you want?
>
>Ord is a "bad" typeclass if you interpret it as "the ordering rules for this type";
>but it is OK if you interpret it as "the default ordering rules for this type".

:-) 
This is the similar linguistic trickery as earler
You can always select a specific instance and claim it default, and then your rule of thumb becomes very very weak.

Lets order some tuples...whats the natural order?..
Ordering the natural numbers, maybe "natural" but I quite often want the reverse order, then I either build custom functions to do this, or have to map between orders (reverse).


> Which,
>arguably, makes more sense for some types
>(Int) and less for others (Text). However, in the case of Ord, there is little harm
>in defining a default instance and using more specialized sorting functions that
>take an explicit ordering functions; this stuff is simple enough for these things to
>not be very intrusive at all, and giving arguable cases the benefit of the doubt, I
>guess, is considered pragmatic.

Ok...but really your rule of thumb says "Ord" is bad...I haven’t got a problem with that...it may be "bad" but still useful enough to preserve....and the language isnt the arbiter of good practice...that's you.

Someone else has used this as a problematic typeclass in another mail (thanks).

you can decide :-)

Is Ord a bad typeclass? Or is the rule of thumb a bit weak (and allows almost any typeclass if we insert the word "default" into the spec)?

(I think Ord is a "bad" typeclass, for your heuristic to survive...and I think your heuristic captures something of value, keep the heuristic and label Ord bad...but still use it).


>
>>
>> There needs to be 1 (or 0) instances because this is all resolved
>> compile time?....i.e. so we (the programmer/compiler) need a function
>> from types, and function name into instances...if there 0
>> instance...then boom...not defined..so you need to do something,
>> that’s fixable....if 2...then boom...you're in trouble?
>
>Sort of, yes. You can't have two instances of the same typeclass for the same
>type. However, because instances are always global, and can be defined
>separately from both the type and the typeclass, it is possible to write instances
>which, when imported, break the code that imports them by introducing
>conflicting instances. This is why the recommendation is to always define
>instances either in the module that defines the type, or the module that defines
>the typeclass. 


Which IS interesting.

Who's recommendation? Have you got a reference? 

> Instances that are defined separately from both are called
>"orphan instances", and people generally avoid them where possible, but
>occasionally practical concerns make them necessary. The most common reason
>for orphan instances is to avoid dependencies: suppose you write a library that
>defines an alternative string type; and someone else writes a library that defines
>useful typeclasses for string-like types. Ideally, you want your custom string type
>to have instances for those typeclasses, but you can't put them in the typeclass
>library (because you don't control it), and you don't want to put them in your
>own library, because then your own library has to depend on the typeclass
>library even though most people won't need that functionality. In such a
>situation, you'd bite the bullet and provide an extra library that contains just the
>instances, peppered with warnings about orphan instances. Another example is
>when you write a program that uses types from some third-party library, and
>wants to marshal them to and from JSON - for that to work, you need to
>implement ToJSON and FromJSON instances for those types, but since you
>control neither the type nor the JSON typeclasses, the only choice you have is to
>make orphan instances in your program. In that case, the damage is limited,
>because you won't expose the orphan instances to the outside world, so it's sort
>of acceptable usually.

Ok...very interesting.

As I say if you've got a reference to some sort of "real world Haskell" book or something like that, then that’s brilliant....I can dig about the edge cases.

CONFIDENTIALITY NOTICE

This e-mail (and any attached files) is confidential and protected by copyright (and other intellectual property rights). If you are not the intended recipient please e-mail the sender and then delete the email and any attached files immediately. Any further use or dissemination is prohibited.

While MTV Networks Europe has taken steps to ensure that this email and any attachments are virus free, it is your responsibility to ensure that this message and any attachments are virus free and do not affect your systems / data.

Communicating by email is not 100% secure and carries risks such as delay, data corruption, non-delivery, wrongful interception and unauthorised amendment. If you communicate with us by e-mail, you acknowledge and assume these risks, and you agree to take appropriate measures to minimise these risks when e-mailing us.

MTV Networks International, MTV Networks UK & Ireland, Greenhouse, Nickelodeon Viacom Consumer Products, VBSi, Viacom Brand Solutions International, Be Viacom, Viacom International Media Networks and VIMN and Comedy Central are all trading names of MTV Networks Europe.  MTV Networks Europe is a partnership between MTV Networks Europe Inc. and Viacom Networks Europe Inc.  Address for service in Great Britain is 17-29 Hawley Crescent, London, NW1 8TT.