F # cuestiones básicas: la mutabilidad, normas de capitalización, funciones vs. métodos

Question

No dude en señalarme a otras respuestas si estos ya se les ha pedido!

estoy empezando F # con la nueva versión de este mes. Tengo un poco de experiencia tanto en OO y lenguajes funcionales (Haskell y el esquema, pero no OCaml / ml). Un par de preguntas han surgido hasta el momento de la lectura a través de la pequeña cosa tutorial que viene con el F # CTP.

1) son variables mutables preferibles a las mónadas? Si es así, se mónadas totalmente rechazados en F #?

2) Estoy un poco confundido por la capitalización que se utiliza. En este archivo de código tutorial, a veces funciones comienzan con una letra minúscula, y, a veces mayúscula. Sé MS tiende a gustaría mayúsculas iniciales con funciones y métodos, pero aquí parece que hay dos maneras de hacerlo. No es un gran problema para mí, ya que sólo estoy jugando en mi propio tiempo, pero tengo curiosidad cuál es el estándar.

3) Estoy bastante confundido acerca de toda esta combinación de estilos OO y funcionales. print_string "string" tiene sentido, pero entonces aquí es List.map fn list (a menos que la lista es sólo el espacio de nombres, perdóname si es así). Entonces aquí es str.Length. A alguien le importa dilucidar cuándo utilizar qué, y los que se prefiere?

Gracias!

Answer 1

En cuanto a la mutabilidad: F # le permite ser pragmático. Rara vez prefiero una mónada estado a un mutable / ref, pero se puede hacer lo que te gusta. Mónadas no son rechazados, pero creo que la gente tiende a utilizar solamente cuando están una victoria clara (por ejemplo asíncrono de programación).

En cuanto a nomenclatura: hay una tensión en el hecho de que 'las funciones son valores' significa que se puede optar por nombrar función let-atado con una letra mayúscula (porque es una función y funciones comienzan con mayúsculas) o con un menor carta -case (porque es un valor Let determinada (que sólo pasa a tener un '->' en su nombre de tipo)). En lo personal yo prefiero usar siempre nombres en mayúsculas para todas las funciones, pero se podrán ver dos estilos (sobre todo porque el estilo de la biblioteca # F en sí ha ido evolucionando poco a poco / estandarización en el último año o dos). Guiones parecen ser evitado en todo .Net, y la biblioteca # F ya no es una excepción (hay algunos nombres dejaron que el uso de relieve, pero ahora se destacan como un pulgar dolorido y probablemente ser cambiados).

En cuanto al estilo función: no tengo muy claro lo que están pidiendo. En el caso de List.map, 'Lista' es el nombre de un F # Módulo , y el 'mapa' es una función de ese módulo. Las funciones miembro (por ejemplo str.length) tienen la ventaja de poder ser utilizado comúnmente a través de .Net, y proporcionan una experiencia agradable IntelliSense en el editor.

Answer 2

1) Yo no iría tan lejos como para decir mónadas son rechazados ... Usted ha mencionado que tiene algunos antecedentes con Haskell - por lo que F # flujos de trabajo son lo que usted desee ver en (el flujo de trabajo plazo tal vez confuso, pero éstos sólo tienen un poquito que ver con la materia de procesos de negocio). En general, las expresiones de secuencia y, más en general expresiones computacional (a.k.a flujos de trabajo) van a estar cerca de mónadas. Dicho mutable es bastante común, aunque no estoy seguro 'preferido' sería la forma de expresarlo. Cada uno tiene un lugar - Personalmente, empecé con dos libros - '# Fundación de F' - pero si usted está buscando para bucear en - ir 'Experto F #' - ambos son buenos. Sinceramente, necesitaba Fundamentos para ayudarme a empezar.

2) En la experiencia que he tenido, la confusión es que las funciones tradicionales de .NET tienen una convención que realmente no se presta a la programación funcional. Como tal, siento que en Fa # que la confusión puede ser a veces cuando usted está buscando en el uso de '.NET tradicional' funciones con nombre frente a elementos de F # que son claramente funcional ... Por ejemplo, en el libro menciono anteriormente 'Experto F #' - mencionan que verá deja valores como List.map y Dates.Today tanto en camelCase y PascalCase (Pascal caso de ser un .NET más tradicional). Una buena regla general es que si te vas a quedar en el mundo funcional - uso más tradicional funcional (camelCase) nombrar - sin embargo, si lo que estás haciendo se espera que sea utilizado por otros lenguajes .NET, ir con el más .NET norma (Pascal). También tenga en cuenta en el mundo funcional hay una tolerancia mucho mayor para la abreviatura (ITR, TBL, etc ...) donde como .NET, en general, se fue lejos de esto ... Así que de nuevo, verá un grado variable de esta tipo de cosas basa en si está llamando elementos funcionales en comparación con los elementos expuestos en Fa # que se comparten en el conjunto de .NET.

3) Estoy de acuerdo en que la combinación de estilos de función OO y puede ser confuso. Una vez más, no estoy seguro de que es el preferido, más allá de decir que F # (siendo funcional) claramente se estilos en términos del paradigma funcional. Sin embargo, F # es un lenguaje funcional en el mundo .NET (notar la confusión relativa de nombrar menciono arriba) ... Así que de nuevo, no es totalmente clara.

Espero que esto ayude ... Lo creas o no, y cuando se utiliza F # y pensar en otros idiomas que han compartido conceptos C ++ con C (por ejemplo) - se hace más fácil. En lo personal, la denominación comenzó a tener sentido y los conceptos trabajó como empecé a conseguir que yo era un F # es un lenguaje funcional que opera en una plataforma tradicional - hecha para interoperar (aunque no estoy seguro de llamar al fisuras interoperación sería apropiado: D)

Answer 3

En mónadas generales ( "flujos de trabajo" en F #) son mucho menos frecuentes que en Haskell, en primer lugar porque las variables mutables están disponibles por lo que es poco probable que la gente elige usar una mónada estado en su lugar. En segundo lugar no hay kinded son de mayor variables de tipo, lo que significa que no se puede escribir código que está sobrecargado para trabajar en cualquier mónada, lo que les facilita el uso mucho menos atractivo.

Uno de los lugares que son de uso común es en las expresiones de secuencia (que en realidad son como listas por comprensión en Haskell, pero los que están estrechamente relacionados con la lista mónada).