[Haskell-cafe] Re: What makes Haskell difficult as .NET?
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 Abcin T {
public IListT abc();
}
- It seems that it is not possible to have default implementations in
interfaces.
To understand the extend haskell supports object oriented behavior
such as inheritance it is worth reading:
http://homepages.cwi.nl/~ralf/OOHaskell/paper.pdf
Perhaps, I should start a new discussion on this.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: What makes Haskell difficult as .NET?
On Fri, 2010-05-14 at 10:40 -0700, Daryoush Mehrtash wrote: In this presentation http://norfolk.cs.washington.edu/htbin-post/unrestricted/colloq/details.cgi?id=907 the speaker talks about F# on .Net platform. Early on in the talk he says that they did F# because haskell would be hard to make as a .Net language.Does anyone know what features of Haskell make it difficult as .Net language? Daryoush 1. Haskell Class/Type famillies/... are conceptually different then classes and interfaces. 2. As .Net does not differentiate between IO a and a Haskell cannot feel completely native (hand-made FFI or everything in IO) 3. .Net does differentiate between variables and functions with 0 arguments. 4. .Net types are not lazy. String is not [Char]. Arrays are used in many places. Regards signature.asc Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: What makes Haskell difficult as .NET?
On Fri, May 14, 2010 at 8:39 PM, Maciej Piechotka uzytkown...@gmail.com 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 Painfully limited, but better than nothing. This would mostly make it problematic to export Haskell functions with type class constraints to other .NET languages, though. I suspect large sections of the .NET libraries could be expressed in Haskell without too much trouble (well, besides everything being in IO), except that getting Haskell to interact nicely with the concept of subtyping in inheritance hierarchies might be awkward. Also potentially problematic is that (if memory serves me) .NET can only handle type parameters with kind *, which excludes types parameterized by type constructors, such as monad transformers. Irritatingly, a lot of stuff in the .NET framework is almost, but not quite, equivalent to some really key bits of Haskell. For instance, Enumerable.SelectA,B(IEnumerableA, FuncA,B) is almost fmap, but returns an existential type instead. I guess IEnumerableT is something akin to Foldable, with cheap kludgy imitations of fmap and (=) bolted on after the fact. Explicit type checks might be necessary in places as well, to deal with .NET's feeble and unreliable type system. Some boilerplate involving Data.Typeable/Data.Dynamic ought to suffice. 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). 3. .Net does differentiate between variables and functions with 0 arguments. Yes, though the latter are easy enough to use. Property getters are nullary functions, likewise the FuncTResult delegate type. You can even write nullary lambda expressions as () = ..., though nullary lambda abstraction is kind of a contradiction in terms. A combination of a nullary pure function and a mutable static variable to cache the result of evaluating it would provide something similar to lazy terms in Haskell. 4. .Net types are not lazy. String is not [Char]. Arrays are used in many places. On the other hand, many of the hot new features on the .NET platform are built around lazy collections with IEnumerableT, which is primarily used as if it were the list monad (e.g., LINQ syntax being sort of a monad comprehension). In summary: So close, yet so far. It'd probably work just well enough to be viable, but be too painful to be enjoyable. I use C# at the day job, so I notice these things often... - C. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
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 uzytkown...@gmail.com
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 Abcin T {
public IListT 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
signature.asc
Description: This is a digitally signed message part
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
