On 05/04/2011 10:59 PM, Ben Kloosterman wrote:
> I do understand them now , but
> knowing when , how and optimally using them is still difficult for me..
>
> - Better support for C++ /C#/Java programmers coming across.
> - Interop with OO Libs
> - Can be more intuitive to code which can help productivity. Type classes to
> me ( which may be because I'm in inexperienced) seem to require a lot more
> thought and planning .
I don't know why you have that impression. Even if all you do is equate
C# interfaces with type classes, you're 90% of the way there. The basics
of type classes aren't hard for developers to understand, particularly
not C# developers. Here's the basic mapping:
class Eq a where
eq: a -> a -> Bool
useEq :: Eq a => a -> a -> Bool
useEq first second = eq first second
maps 1:1 to C#:
interface IEquatable<T>
{
bool Equals(T first, T second);
}
bool UseEq<T>(T first, T second)
where T : IEquatable<T>
{
return first.Equals(second);
}
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.
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. If C#
allowed you to implement an interface for a pre-existing type, you would
then have exactly type classes. Thus, type classes + existentials are
strictly more general than interfaces alone. Multiparameter type classes
generalize this even further.
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.
Which isn't to say type classes couldn't be made simpler, and I have
some ideas on this, but BitC isn't the place for research. I think BitC
is on the right path here with lexically scoped instances though.
Sandro
_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev
