Soy desarrollador .NET por día, pero he estado jugando con Haskell en mi tiempo libre por un tiempo. Tengo curiosidad: ¿alguna implementación Haskell .net en la misma línea que IronPython?Haskell para la plataforma .net?
No hay un trabajo activo para transferir el tiempo de ejecución de GHC a .NET.
F # es lo más parecido, aunque tenga en cuenta que se basa en OCaml, y como tal, no se basa en la transparencia referencial por defecto, como es Haskell.
¿Puede ampliar por qué la transparencia referencial por defecto es algo bueno? – knocte
@knocte Porque de esa manera no se pueden limitar las operaciones de efecto secundario y el estado inmutable se aplica con mayor fuerza, lo que lleva a un código que se puede razonar con mayor facilidad (y menos errores). – BalinKingOfMoria
Eso es lo que F# es para.
No conozco ni Haskell ni F # lo suficientemente bien para comparar, pero en términos de lenguajes funcionales en la plataforma .NET, sospecho que F # arrinconará el mercado simplemente porque es compatible con Microsoft e incluido en Visual Studio (comenzando en 2010 , pero puede obtener complementos para versiones anteriores de VS). –
No, F # se deriva de OCaml, que es una historia diferente a Haskell que se basa más en LISP. –
@Johannes Rudolph: ¿Qué? No, Haskell tiene muy poco en común con LISP, pero es un primo (algo distante) de la familia ML. F # también extrae algunos puntos de inspiración adicional de Haskell, al igual que C#, y gran parte del trabajo realizado en Haskell como idioma está financiado por Microsoft Research. –
No conozco .net Haskell, pero hay otro lenguaje funcional disponible: F#. Se ejecuta en .Net y viene con Visual Studio. Son similar a un punto; esto stackoverflow question explica las diferencias.
Aquí está la documentación en getting started with F#.
Gracias. He jugueteado tanto con F # como con OCaml, pero prefiero haskell. – Will
Haskell no funcionaría muy bien en .NET sin algunos grandes cambios en el tiempo de ejecución o tal vez un compilador realmente inteligente.
Quizás las cosas cambien cuando los contratos de código impregnan más, pero en este momento, incluso las funciones que son realmente puras en comportamiento, como las funciones de manipulación de cadenas, tendrían que accederse a través de IO, así que no valdría la pena en absoluto.
Eso, y hay problemas de optimización - .NET no hace ninguna optimización para objetos inmutables, por ejemplo, listas (secuencias como se llaman en F #, o IEnumerable como se llaman en C#) no sería tan eficiente.
Un compilador Haskell IL podría ser factible, como algo que escupe ensamblados .NET en lugar de x86 .exes/.dlls.
Si bien esta pregunta es específicamente sobre .NET, tengo curiosidad de saber si los mismos argumentos se mantienen si Haskell se ejecutara en la JVM. ¿La JVM, por ejemplo, realiza más optimizaciones en objetos inmutables que la CLR? – stakx
Hasta donde yo sé, la situación es la misma con la inmutabilidad. Me imagino que la optimización de la inmutabilidad es bastante complicada, equilibrando la memoria y los costos de rendimiento, etc. El recolector de basura probablemente también se vea diferente, y JVM y .NET comparten recolectores de basura similares. Una cosa que .NET 4 tiene es la optimización de recursividad de cola, que ayuda a simplificar los compiladores funcionales, pero solo lo proporcionaron para x64 y no para x86, que es una decisión que me desconcierta más allá de las palabras. –
@stakx: si realmente quieres saber, estoy seguro de que hay mucho material sobre ese tema de parte de las personas que trabajan en Scala y Clojure. Si la memoria me sirve, Clojure, en particular, pone gran énfasis en los datos inmutables. –
Ver hs-dotnet: Pragmatic .NET interop for Haskell
hs-dotnet es una capa de interoperabilidad .NET pragmática para Haskell. Expone ambas clases .NET a Haskell (a través de GHC) y valores de función Haskell a .NET.
Probado en .NET 3.5, lo que significa que también funcionará en un proyecto .NET 4.0. – Contango
¿Has visto el [sitio web H #] (http://www.cin.ufpe.br/~haskell/haskelldotnet/)? (En realidad, ese sitio parece bastante ... muerto para mí.) – stakx
@stakx: "Últimas noticias: 2003-12-13" Sí, lo vi. :) – Will
** Incluso si encuentra una plataforma satisfactoria **, es importante que consulte [la respuesta de Rei aquí] (http://stackoverflow.com/a/3269215/825637) porque no se puede ignorar que la CLR no está construido para esto. – MasterMastic