> Any type class you'd care to name has a direct translation to interfaces and > vice versa. If you're not sure whether to use a type class, just ask yourself > whether you'd use an interface.
That's a useful pointer though it's a bit more than that as it also covers templates/genrics . These days in C# I just write the first class and use extract interface when I hit a second case which is useful for me to stop wasting time in design land. > > The problem with interfaces is that you cannot implement an interface on > someone else's type. For instance, I can't now declare that both > System.Int32 and System.Int16 implement an IArithmetic interface. > > Type classes require planning only to the extent that any abstraction requires > planning. Requiring an interface for a parameter means you're declaring your > intent to allow clients to parameterize the behaviour of one abstraction by > another abstraction, so the interface must declare a contract satisfiable by a > number of possible implementations. The same problem applies to both > type classes and interfaces. I don't disagree with you here and I think its primarily lacking writing enough code that said the simple option of the higher abstractions is exactly what causes the issue since you can do it , I start going should I ? At the moment in C# you use Interfaces easily but moving to generics and templates requires a bit more planning / thought / time so will only be done if needed , with type classes you are immediately confronted with such questions like the Constraints (which exist on Genrics) , unboxed types , how member methods/ functions fit etc . Unlike Haskell Bitc also has better unboxed type support and member functions which makes the choice harder. And since they map almost 1:1 some interface like Syntax that overlaps is cheap to implement and may be useful to cover simple type classes which experienced programmers will eventually be weaned of by burying the detail in an advanced section . It also serves other rolls eg Interop to OO libs ( since you can specify an external class as an interface ) , as a grouping mechanism , and to indicate always boxed types , you may support attributes on them which is VERY useful for interop etc . If you have interfaces ( as an alias say for type classes) I bet C# and Java programmers will immediately be much more productive which is important when evaluating a new language . Without this they may have strange behavior due to unboxed types and they will also read/investigate type classes more and become confused by the higher ordered options and when to use them etc. Like other higher order options writing your own Generics / Templates these should be in the Advanced section at the back. Agree it's a decision that you may regret if BitC becomes big but it may help it getting there.. An alternative is better documentation and putting the higher ordered abstractions for type classes in the sealed section at the back ;-) Though you still need something to help interop you don't want to overload type classes too much Im against inheritance however. Ben _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
