F # se deriva de OCaml, pero ¿qué elementos principales faltan o se agregan? Específicamente, tengo curiosidad por saber si los recursos disponibles para aprender OCaml también son útiles para alguien que quiera aprender F #.
Otra comparación desde la perspectiva de un desarrollador de OCaml, por lo que es bastante parcial pero útil de todos modos.
Mauricio Scheffer
8
Atención: si está interesado en el destino de esta pregunta, únase a la discusión sobre Meta Stack Overflow o discútala en el chat : los comentarios aquí fueron extraordinariamente improductivos, por lo que los eliminé.
Shog9
1
@MauricioScheffer ¡Enlace roto!
JD
2
@ JonHarrop Creo que este enlace podría ser el actualizado. (Por Keiko Nakata)
Bart
Respuestas:
89
Las principales diferencias son que F # no admite:
functors
Objetos de estilo OCaml
variantes polimórficas
el preprocesador camlp4 / 5 o puntos de extensión (ppx)
Además, F # tiene una sintaxis diferente para los parámetros etiquetados y opcionales.
En teoría, los programas OCaml que no usan estas características se pueden compilar con F #. Aprender OCaml es una introducción perfectamente razonable a F # (y viceversa, me imagino).
La lista completa de diferencias está aquí (nota: reemplazo de archivo muerto de archive.org).
No lo creo Pero probablemente podría canalizar su programa a través de camlp4 y al compilador de F #. (No lo recomendaría.)
Chris Conway
66
F # tiene argumentos con nombre y opcionales, pero utiliza una sintaxis y semántica diferentes. Tendrá problemas para usar Camlp4 con F # porque F # es casi siempre sensible a la sangría, por lo que necesitará un nuevo lexer y la documentación de Camlp4 en lexers ha permanecido sin escribir durante casi dos años.
JD
44
Y ahora el enlace está muerto. Supongo que probablemente sea bueno. Estoy seguro de que F # ha mejorado desde el '08.
1
Escuché en alguna parte que Microsoft no quería agregar una funcionalidad similar a camlp4 a F # porque les preocupaba que tal funcionalidad pudiera alentar a las personas a comenzar a usar entornos de desarrollo que no sean Microsoft Visual Studio.
chrismamo1
118
Esta pregunta se ha respondido desde hace algún tiempo, pero me sorprendió bastante que la mayoría de las respuestas digan qué características de OCaml faltan en F #; esto es definitivamente bueno saber si desea portar los programas de OCaml existentes a F # (que probablemente sea el motivación de la mayoría de los artículos referenciados). Sin embargo, hay muchas características que hacen de F # un idioma diferente (¡no solo una versión limitada de OCaml para .NET!) Aquí hay un par de cosas que se agregan en F #:
Unidades de medida que le permiten escribir código de verificación que trata con cálculos numéricos
Metaprogramación utilizando citas (lo que hace posible usar LINQ en F # y también es esencial para proyectos prometedores como la plataforma WebSharper)
Patrones activos para crear abstracciones para tipos de datos funcionales (y generalmente característica muy útil para aplicaciones de coincidencia de patrones más complicadas)
Expresiones de cálculo, que es una característica del lenguaje detrás de los flujos de trabajo asíncronos (una biblioteca para E / S asíncrona / servicio web / programación de GUI)
Sistema de objetos compatible con .NET que hace posible la interoperabilidad total con la plataforma .NET (OCaml también tiene soporte para objetos pero diferentes; por supuesto, hay algunos beneficios en ambos sistemas).
Operadores sobrecargados : hasta donde yo sé, OCaml no tiene operadores sobrecargados; en F # puede usarlo +para todos los tipos numéricos, así como para los tipos que lo admiten.
Y, sinceramente, creo que también vale la pena mencionar el IDE de Visual Studio. Esto no es parte del lenguaje, pero realmente mejora la experiencia del usuario (¡el soporte de IntelliSense en Visual Studio es realmente bueno!)
Si observa la lista, hay muchas cosas que contribuyeron en gran medida a la popularidad de F #, por lo que es mucho más que simplemente "OCaml sin functors". F # se basa definitivamente en OCaml (y toma ideas de otros idiomas como Haskell) y comparte muchos aspectos con ellos, sin embargo, también hay muchas otras cosas. Supongo que sin cosas como flujos de trabajo asincrónicos, OO de estilo .NET y metaprogramación, la División de Desarrolladores de Microsoft nunca incluiría F # en Visual Studio 2010.
Woah! OCaml fue criado específicamente para la metaprogramación, es muy superior a F # y .NET en ese contexto. Camlp4 es un sistema de cotización mucho más poderoso que F # 's. Los lexers y analizadores de OCaml son mucho mejores que cualquier cosa disponible para .NET. Además, las macros Camlp4 están disponibles para implementar patrones activos y expresiones de cálculo. OCaml también tiene IDE que proporcionan los mismos beneficios que Visual Studio ofrece para F #.
JD
44
Sin embargo, las citas de F # tienen un objetivo completamente diferente al que está disponible en Camlp4 (aparte, este no es el lenguaje OCaml, es un sistema además), por lo que no es justo compararlas. La existencia de Camlp4 es ciertamente una ventaja de OCaml, pero no tiene nada que ver con citas (que permiten cosas como WebSharper, ejecutar F # en GPU, etc.)
Tomas Petricek
12
@Tomas: ¿Cómo puede conciliar su afirmación de que Camlp4 "es un sistema además de" OCaml cuando Camlp4 está integrado con OCaml a nivel binario y las macros Camlp4 se pueden definir y utilizar sobre la marcha en un OCaml REPL en ejecución? ¿Cómo conciliar su afirmación de que Camlp4 "no tiene nada que ver con las citas" con el hecho de que Camlp4 proporciona un mecanismo de citas? ¿Cómo concilias tu implicación de que Camlp4 no puede facilitar los gustos de Websharper cuando la herramienta ocamljs de SkyDeck ha estado compilando el código OCaml citado usando Camlp4 a Javascript desde 2007?
JD
66
@Tomas: F # ni siquiera puede citar expresiones con variables no vinculadas como <@ a @>, y mucho menos escribir definiciones como <@ type t = int @>y no puede manejar gramáticas arbitrarias, mucho menos lexers y analizadores extensibles como lo hace Camlp4. La falta de un sistema macro decente es una deficiencia, pero, en mi humilde opinión, la falta de lexers y analizadores decentes para F # es un impedimento mucho más grave. De hecho, ¡aconsejo a los desarrolladores que creen sus lexers y analizadores utilizando OCaml, restringiéndose al subconjunto que admite F # y transfiriéndolo de nuevo a F # para beneficiarse del soporte de herramientas superior de OCaml!
JD
8
@Erik: "La mayoría de las personas se centran en lo que falta en F #, pero también quería ver lo que faltaba en OCaml". Tenga en cuenta que los patrones activos, la metaprogramación, las expresiones de cálculo y los flujos de trabajo asíncronos estaban disponibles en OCaml antes de que se convirtieran en F #.
JD
16
Siempre describo a F # como primo de OCaml porque OCaml tiene muchas características que F # no tiene y que probablemente nunca tendrá. F # está más estrechamente relacionado con el lenguaje CAML anterior. En particular, F # tiene un soporte muy limitado para la abstracción y ningún soporte para la tipificación estructural (como los objetos de OCaml y las variantes polimórficas ).
Al contrario de lo que han escrito algunos encuestados, F # tiene soporte (limitado) para argumentos etiquetados ("con nombre") y opcionales.
Sin embargo, estas son todas características avanzadas y ciertamente puede comenzar a familiarizarse con las ideas básicas detrás de la programación funcional de estilo OCaml a pequeña escala utilizando recursos sobre OCaml. La primera gran diferencia que descubrirá son los problemas a mayor escala, como la encapsulación y la abstracción, que se resuelven de maneras completamente diferentes en OCaml y en F #. Si desea aprender cómo hacerlo en F #, la única literatura disponible es este artículo sobre estructuras de datos puramente funcionales .
También descubrí que el maravilloso sistema de módulos de OCaml facilita la parametrización del código sobre los tipos (como las estructuras de datos), pero las alternativas OOP no solo son horribles sino que casi no se usan en .NET. Además, cuando intento escribir estructuras de datos elegantemente parametrizadas, encuentro docenas de errores en el compilador de F # porque nadie ha intentado hacerlo antes. El F # stdlib contiene algunas implementaciones agradables de la estructura de datos, pero prácticamente no se reutiliza, es decir, es un trabajo de cortar y pegar.
@Parecerán ser un complemento descarado para las cosas que Jon Harrop escribió él mismo (aparece como autor cada vez)
simbionte el
@symbiont Sí, sabemos que es un poco spam. Sería bueno si se vincula a alguna información adicional que es gratuita. Pero la respuesta está bien sin los enlaces, así que ahí estás.
@Will sería bueno si vinculara alguna información adicional usted mismo
simbionte
@symbiont Quise decir Jon, no tú, cuando dije "tú". Suena raro leerlo. No estoy seguro si Jon eliminó un comentario intersticial. De todos modos, aquí tienes: Meta Stack Exchange
9
F # y OCaml son clases taxonómicas en la familia de idiomas ML, que también incluye un conjunto completo de otros animales extraños. F # es más nuevo que OCaml, y todavía no tiene functores [funciones del módulo -> módulo] o tipos de fila [clases de objetos y variantes polimórficas]. Entre ellas, esas dos simplificaciones probablemente hagan que la curva de aprendizaje sea más fácil para alguien que desarrolle en la plataforma .Net. Lamentablemente, esas dos características del lenguaje son muy poderosas en OCaml, por lo que leer la literatura de OCaml para obtener información sobre cómo codificar F # probablemente conducirá a una frustración prematura con este último cuando probablemente sea una excelente alternativa a C # donde ambos están disponibles.
"F # admite la sintaxis de OCaml directamente. Puede que no sea 100% compatible, pero creo que está bastante cerca". IME, el soporte del compilador F # para compatibilidad OCaml es muy defectuoso. Esto puede dificultar la transferencia de bases de código OCaml existentes a F # porque el compilador de F # muere internamente en un código válido.
Respuestas:
Las principales diferencias son que F # no admite:
Además, F # tiene una sintaxis diferente para los parámetros etiquetados y opcionales.
En teoría, los programas OCaml que no usan estas características se pueden compilar con F #. Aprender OCaml es una introducción perfectamente razonable a F # (y viceversa, me imagino).
La lista completa de diferencias está aquí (nota: reemplazo de archivo muerto de archive.org).
fuente
Esta pregunta se ha respondido desde hace algún tiempo, pero me sorprendió bastante que la mayoría de las respuestas digan qué características de OCaml faltan en F #; esto es definitivamente bueno saber si desea portar los programas de OCaml existentes a F # (que probablemente sea el motivación de la mayoría de los artículos referenciados). Sin embargo, hay muchas características que hacen de F # un idioma diferente (¡no solo una versión limitada de OCaml para .NET!) Aquí hay un par de cosas que se agregan en F #:
+para todos los tipos numéricos, así como para los tipos que lo admiten.Y, sinceramente, creo que también vale la pena mencionar el IDE de Visual Studio. Esto no es parte del lenguaje, pero realmente mejora la experiencia del usuario (¡el soporte de IntelliSense en Visual Studio es realmente bueno!)
Si observa la lista, hay muchas cosas que contribuyeron en gran medida a la popularidad de F #, por lo que es mucho más que simplemente "OCaml sin functors". F # se basa definitivamente en OCaml (y toma ideas de otros idiomas como Haskell) y comparte muchos aspectos con ellos, sin embargo, también hay muchas otras cosas. Supongo que sin cosas como flujos de trabajo asincrónicos, OO de estilo .NET y metaprogramación, la División de Desarrolladores de Microsoft nunca incluiría F # en Visual Studio 2010.
fuente
<@ a @>, y mucho menos escribir definiciones como<@ type t = int @>y no puede manejar gramáticas arbitrarias, mucho menos lexers y analizadores extensibles como lo hace Camlp4. La falta de un sistema macro decente es una deficiencia, pero, en mi humilde opinión, la falta de lexers y analizadores decentes para F # es un impedimento mucho más grave. De hecho, ¡aconsejo a los desarrolladores que creen sus lexers y analizadores utilizando OCaml, restringiéndose al subconjunto que admite F # y transfiriéndolo de nuevo a F # para beneficiarse del soporte de herramientas superior de OCaml!Siempre describo a F # como primo de OCaml porque OCaml tiene muchas características que F # no tiene y que probablemente nunca tendrá. F # está más estrechamente relacionado con el lenguaje CAML anterior. En particular, F # tiene un soporte muy limitado para la abstracción y ningún soporte para la tipificación estructural (como los objetos de OCaml y las variantes polimórficas ).
Al contrario de lo que han escrito algunos encuestados, F # tiene soporte (limitado) para argumentos etiquetados ("con nombre") y opcionales.
Sin embargo, estas son todas características avanzadas y ciertamente puede comenzar a familiarizarse con las ideas básicas detrás de la programación funcional de estilo OCaml a pequeña escala utilizando recursos sobre OCaml. La primera gran diferencia que descubrirá son los problemas a mayor escala, como la encapsulación y la abstracción, que se resuelven de maneras completamente diferentes en OCaml y en F #. Si desea aprender cómo hacerlo en F #, la única literatura disponible es este artículo sobre estructuras de datos puramente funcionales .
También descubrí que el maravilloso sistema de módulos de OCaml facilita la parametrización del código sobre los tipos (como las estructuras de datos), pero las alternativas OOP no solo son horribles sino que casi no se usan en .NET. Además, cuando intento escribir estructuras de datos elegantemente parametrizadas, encuentro docenas de errores en el compilador de F # porque nadie ha intentado hacerlo antes. El F # stdlib contiene algunas implementaciones agradables de la estructura de datos, pero prácticamente no se reutiliza, es decir, es un trabajo de cortar y pegar.
fuente
F # y OCaml son clases taxonómicas en la familia de idiomas ML, que también incluye un conjunto completo de otros animales extraños. F # es más nuevo que OCaml, y todavía no tiene functores [funciones del módulo -> módulo] o tipos de fila [clases de objetos y variantes polimórficas]. Entre ellas, esas dos simplificaciones probablemente hagan que la curva de aprendizaje sea más fácil para alguien que desarrolle en la plataforma .Net. Lamentablemente, esas dos características del lenguaje son muy poderosas en OCaml, por lo que leer la literatura de OCaml para obtener información sobre cómo codificar F # probablemente conducirá a una frustración prematura con este último cuando probablemente sea una excelente alternativa a C # donde ambos están disponibles.
fuente
F # admite la sintaxis de OCaml directamente. Puede que no sea 100% compatible, pero creo que está bastante cerca.
http://plus.kaist.ac.kr/~shoh/fsharp/html/index.html
Aquí hay una lista de diferencias (no estoy seguro de qué tan actualizada está)
http://plus.kaist.ac.kr/~shoh/fsharp/html/fsharp-vs-ocaml.html
fuente