Re: [Haskell-cafe] Re: What makes Haskell difficult as .NET?

On Fri, 2010-05-14 at 22:54 -0400, C. McCann wrote:

On Fri, May 14, 2010 at 8:39 PM, Maciej Piechotka wrote:

...

1. Haskell Class/Type famillies/... are conceptually different then classes and interfaces.

I believe interfaces would be roughly equivalent to the subset of single-parameter type classes such that: - All type class methods are functions - The first argument of each function is the class's type parameter, fully applied to any type parameters it needs - The class's type parameter appears nowhere else

I'm not sure but also: - you can write always a new class in Haskell: class Abc x where abc :: x -> Int instance Abc Int where abc = id IIRC .Net interfaces cannot be added outside assembly (I may be wrong). On the other hand Haskell does not have inheritance. Generally Haskell: newtype/data specify data (and type) while classes provides basic abstract operations on it. C#/Java/...: Classes specify data AND how to operate on it (including non-basic operators) and interfaces abstract operations. - It is not that it can occur once: class Abc x where abc :: x -> [x] is roughly: interface Abc<in T> { public IList<T> abc(); } - It seems that it is not possible to have default implementations in interfaces.

...

2. As .Net does not differentiate between IO a and a Haskell cannot feel completely native (hand-made FFI or everything in IO)

Wouldn't be any worse than using most C bindings in Haskell as is. Or using a lot of .NET libraries in F#, to be honest, if you try to write functional-idiomatic instead of quasi-imperative code.

Though, considering the near-omnipresent possibility of null references, most .NET functions would actually need to return something of the form "IO (Maybe a)".

However the problem is that the .Net is suppose to be a single platform with different syntaxes attacked to it. It does not stop to use F# operations (without syntax sugar) in C# or VB. Haskell on .Net would be a foreigner as it is on C. Regards