Ce texte est une traduction gratuite d'une série d'articles de Sacha Barber de Brighton, au Royaume - Uni, que j'ai trouvé assez intéressants.Ceci est le premier article de ma série F #. Alors qu'allons-nous couvrir? Comme de nombreux programmeurs le savent bien, il est habituel de commencer par l'exemple de Hello World.
Nous allons donc faire exactement cela. Donc, sans plus tarder, ce dont vous avez besoin pour créer une application séparée "Hello World" en F #.
Le voici:
open System [<EntryPoint>] let main argv = printfn "Hello World" Console.ReadLine() |> ignore 0
// Malheureusement, je n'ai pas pu trouver l'allocation de code pour F #Cela peut ne pas sembler suffisant pour en discuter, mais il y a déjà quelque chose à considérer pour plonger dans certains des principes de F #.
Alors que se passe-t-il exactement ici?
Comme il s'agit d'une application distincte, nous avons évidemment besoin d'un point d'entrée (comme pour tout autre langage .NET).
Alors, comment le point d'entrée est-il déterminé?
Eh bien, c'est presque la même chose qu'avec les autres langages .NET, nous avons une méthode Main (ou une fonction dans la terminologie F #) qui prend un tableau de chaînes, et nous utilisons l'attribut [] pour indiquer que la méthode avec cet attribut est point d'entrée.
Le compilateur et Visual Studio nous aiment pour cela.
Même dans cet exemple, vous devriez entendre des sonneries d'alarme ou au moins un certain sentiment de malentendu. Donc, nous avons dit qu'il existe une fonction initiale qui prend un tableau de type chaîne. Tout ce que je vois est une variable nommée «argv», que je ne vois pas déclarée comme un tableau. Cette variable "argv" est évidemment le tableau de chaînes que nous attendons, mais pourquoi il n'a pas de type .... Mmm, intéressant.
F # a un très bon système d'inférence de type, ce qui signifie que dans de nombreux cas, vous pouvez omettre le type du tout, et F # le sortira correctement. Bien sûr, vous pouvez toujours déclarer complètement le type de la variable d'entrée si vous le souhaitez, où il prend généralement la forme
(variableName: variableType)Par conséquent, en prenant l'exemple «argv» ci-dessus, nous pourrions plutôt déclarer le programme ci-dessus comme suit, et ce serait bien:
open System [<EntryPoint>] let main (argv :string[]) = printfn "Hello World" Console.ReadLine() |> ignore 0
Vous voyez, nous avons entièrement défini le nom de la variable d'entrée avec son type, qui dans ce cas est un tableau de chaînes [].
Qu'est-ce qui s'y intéresse d'autre? Eh bien, comme je l'ai dit, il y a de quoi parler.
Pourquoi ai-je une ligne avec cet étrange
|> ignorer à la fin. Qu'est ce que c'est
Eh bien, comme il s'agit d'une application console F #, je voulais que l'application ne s'arrête pas tant que l'utilisateur n'a pas entré de caractère. Je dois donc faire 2 choses:
- Ouvrez l'espace de noms "System", qui me permet d'utiliser les types d'espaces de noms "System", un peu comme si j'utilisais "using System" en C # ou "Imports System" en VB .NET. "
- Étant donné que F # est un langage fonctionnel, il se plaindra si la fonction, dans ce cas, «Console.ReadLine (...)», qui peut renvoyer une chaîne, ne transmet pas le résultat plus loin à la fonction «ignorer», ce qui signifie en fait return () (c'est le moyen en F # dites vide, mais ça s'appelle Unit). Cela indique explicitement à F # d'ignorer le résultat de l'appel de la méthode Console.ReadLine (..).
Par exemple, voici à quoi ressemblera le code si je décide de ne pas inclure |> ignorer
Le programmeur C # / VB.NET peut ne pas voir ce qui est dit ici. Mais F # est assez dur sur ce qu'une fonction peut et ne peut pas faire. Et une chose qu'une fonction DEVRAIT TOUJOURS faire est de renvoyer un résultat. Dans le cas de la fonction "principale", le résultat attendu sera une valeur entière de 0.
Mais qu'en est-il du cas de Console.ReadLine (..)?
Eh bien, au moins dans ce cas, le résultat n'a pas beaucoup d'importance, et cela ne nous intéresse pas, et le programme fonctionnera toujours bien si nous sautons
|> ignorer , mais si vous n'êtes vraiment pas intéressé par le résultat, vous devriez apprendre à utiliser
|> ignorer . Juste au cas où vous êtes intéressé, l'opérateur de pipeline "|>" dirigera la valeur de retour de l'expression gauche vers la fonction de droite, qui dans ce cas est égal à
"accepte la valeur de retour de Console.Readline (...) et ignorera à quel point personne ne s'en soucie .
" Ne vous inquiétez pas si cela ne vous dit rien à ce stade, nous en reparlerons plus tard.
La dernière chose que je dois faire est de m'assurer que la fonction F # retourne toujours une valeur, cela se fait dans la ligne où vous voyez juste la ligne 0. Cela suffit pour que F # comprenne qu'il s'agit de la valeur de retour "0", que le système d'inférence de type affichera, il s'agit d'une valeur Int de 0. La raison pour laquelle le compilateur F # sait qu'il s'agit d'une valeur de retour est que dans ce cas, il s'agit de la dernière instruction, il DOIT donc être une valeur de retour. Évidemment, cela peut être compliqué en utilisant une logique conditionnelle si, sinon, etc. Il est important de noter qu'en F # la fonction DEVRAIT TOUJOURS retourner une valeur, et dans ce cas, comme la valeur de 0 Int était la dernière chaîne trouvée (bien que tout puisse être plus compliqué), elle est utilisée comme valeur de retour. Bien sûr, vous pouvez retourner Unit, ce qui se fait en utilisant "()", qui ne retourne en fait rien (nul si vous le souhaitez).
Une autre chose que je voudrais mentionner dans cet exemple trivial est que l'espace joue un rôle clé dans le développement de F #.
Par exemple, supposons que mon exemple trivial ressemble à ceci dans un éditeur (dans mon cas, Visual Studio 2012):
Ceci est un petit programme, et tout ce que j'ai fait a été de supprimer les espaces au début de la ligne printfn. Mmmm, il semble que le compilateur F # n'aimait pas ça du tout. Oui, c'est juste.
En F #, un espace est TRÈS TRÈS important, alors jouez bien avec lui, sinon habituez-vous au débogage des erreurs cryptiques comme celle montrée ci-dessus, qui est causée par un simple problème d'espace sémantique incorrect.
Quoi qu'il en soit, ceci est un exemple de «Hello World». Jusqu'à notre prochaine rencontre, je vous souhaite le meilleur.