F# 2.0 et Visual Studio 2010

**LLB** · 14/04/2010, 17h18

Comme ce forum manque un peu d'activité, je fais un petit message pour informer des nouveautés.

La version finale de Visual Studio 2010 vient tout juste de sortir et cela inclut F# 2.0.

F# n'a pas beaucoup changé depuis la dernière Release Candidate (j'en avais parlé), à part des bug fixs. Toujours est-il qu'on a enfin une version stable et production-ready.

**Dim Me As New Idiot** · 16/04/2010, 09h20

Je l'utilise sous Mono et je dois dire que cela fonctionne plutôt bien

**LLB** · 16/04/2010, 09h56

Ouais, il y a eu pas mal de travail à ce niveau-là, mais ça devrait encore être considérablement amélioré cette année (cf. cette offre).

**Dim Me As New Idiot** · 16/04/2010, 11h23

Oui il y a aussi ce message sur le blog de Miguel de Icaza qui indique que la prochaine version de mono ajoutera la tailcall optimization (et donc un meilleur support de F#).

**Dim Me As New Idiot** · 18/05/2010, 15h00

Bon finalement, F# et Mono c'est pas encore ça

Il y a encore de gros problèmes lorsque l'on fait de la composition de fonction ou lorsque l'on veut appeler des fonctions dans un when guard.

**LLB** · 18/05/2010, 18h04

Je peux voir l'erreur ?

**Dim Me As New Idiot** · 19/05/2010, 10h00

Tous les morceaux de code qui vont suivre fonctionne avec la CLR de Microsoft. Par contre certains d'entre-eux ne fonctionnent pas avec la version 2.6.3 de Mono.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
 
>let whenGuardFailure cardsArray =
-    let subFunc v1 v2 v3 v4 =
-        v1 + v2 + v3 + v4
-    match cardsArray with
-    | [| v1; v2; v3; v4 |] when subFunc v1 v2 v3 v4 = 40 -> printfn "Excellent!"
-    | _                                                  -> printfn "Bouh!"
-
-whenGuardFailure [| 10; 10; 10; 10 |];;
Excellent!

Ici le code fonctionne comme sur la CLR de Microsoft.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
 
>let whenGuardFailure cardsArray =
-    let subFunc v1 v2 v3 v4 =
-        v1 = v2 && v2 = v3 && v3 = v4
-    match cardsArray with
-    | [| v1; v2; v3; v4 |] when subFunc v1 v2 v3 v4 -> printfn "Excellent!"
-    | _                                             -> printfn "Bouh!"
-
-whenGuardFailure [| 10; 10; 10; 10 |];;
System.InvalidProgramException: Invalid IL code in FSI_0028:whenGuardFailure<int> (int[]): IL_0117: ret       
 
 
  at <StartupCode$FSI_0028>.$FSI_0028.main@ () [0x00000] 
  at (wrapper managed-to-native) System.Reflection.MonoMethod:InternalInvoke (object,object[],System.Exception&)
  at System.Reflection.MonoMethod.Invoke (System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x00000] 
Stopped due to error

Dans ce code, j'ai remplacé les opérations d'additions par des tests d'égalités dans la sous fonction et là, c'est le drame

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
 
>type Suit =
-    | H
-    | D
-    | S
-    | C
-
-type PlayingCard = Card of int * Suit
-
-let whenGuardFailure cardsArray =
-    let subFunc v1 v2 =
-        v1 = v2
-    match cardsArray with
-    | [| Card (v1, _); Card (v2, _) |] when subFunc v1 v2 -> printfn "Excellent!"
-    | _                                                   -> printfn "Bouh!"
-
-whenGuardFailure [| Card (10, H); Card (10, D) |];;
Excellent!

Dans ce test ci, j'utilise des types sommes et tout se déroule normalement.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
 
>let whenGuardFailure cardsArray =
-    let subFunc v1 v2 v3 v4 =
-        v1 = v2 && v2 = v3 && v3 = v4
-    match cardsArray with
-    | [| Card (v1, _); Card (v2, _); Card (v3, _); Card (v4, _) |] when subFunc v1 v2 v3 v4 -> printfn "Excellent!"
-    | _                                                   -> printfn "Bouh!"
-
-whenGuardFailure [| Card (10, H); Card (10, D); Card (10, S); Card (10, C) |];;
System.InvalidProgramException: Invalid IL code in FSI_0013:subFunc@89-4<int> (int,int,int,int): IL_004f: ret       
 
 
  at FSI_0013.whenGuardFailure (.PlayingCard[] cardsArray) [0x00000] 
  at <StartupCode$FSI_0013>.$FSI_0013.main@ () [0x00000] 
  at (wrapper managed-to-native) System.Reflection.MonoMethod:InternalInvoke (object,object[],System.Exception&)
  at System.Reflection.MonoMethod.Invoke (System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x00000] 
Stopped due to error

Par contre dans cet exemple, j'ai seulement ajouté des paramètres à la fonction et visiblement il n'apprécie pas

**LLB** · 02/06/2010, 17h40

Merci !

Pour info, c'est un bug de Mono lié à la génération dynamique de code (reflection.emit) avec les generics. L'équipe de Mono est au courant.

En attendant, pour contourner le problème, tu peux compiler ton code avec fsc ou ajouter des annotations de type.

**Dim Me As New Idiot** · 13/09/2010, 17h24

J'ai testé avec une version preview de Mono 2.8 et effectivement c'est corrigé

**LLB** · 13/09/2010, 18h05

Envoyé par Dim Me As New Idiot

J'ai testé avec une version preview de Mono 2.8 et effectivement c'est corrigé

En effet ! Mais tu risques de rencontrer parfois des "Operation is not supported" (qui disparaitront dans la prochaine mise à jour de F#).

**Dim Me As New Idiot** · 14/09/2010, 09h47

Merci pour la précision!

Au fait tu sais si le support complet du langage (tail call opt, ...) a été implémentée dans la prochaine release de Mono ? Je te demande ça parce que la release note n'en fait pas mention.

**LLB** · 14/09/2010, 11h48

Pour les tail calls, il n'y a pas encore eu de changement et je ne sais pas s'il y en aura. Pour le moment, il sont optimisés dans pas mal de cas, mais pas tous (cela dit, sous le .NET de Microsoft, on trouve également des restrictions, surtout en 64 bits, et les specs n'imposent rien).

Si tu trouves des bugs en compilant avec fsc, n'hésite pas à les signaler. Novell et Microsoft souhaitent tous deux améliorer la compat F#/Mono.

**Dim Me As New Idiot** · 03/11/2010, 09h32

Bon il semblerait que le support des Tail Call Optimizations soit prévu pour la prochaine version de mono

**LLB** · 04/11/2010, 13h50

Demain, F# (le compilo et la bibliothèque standard) seront publiés sous licence Apache 2.0.

**LLB** · 05/11/2010, 02h14

C'est fait : http://blogs.msdn.com/b/dsyme/archiv...code-drop.aspx

**Dim Me As New Idiot** · 05/11/2010, 10h24

Quelle bonne nouvelle

Mais concrètement qu'est que cela va changer ?

**LLB** · 05/11/2010, 12h28

Tu peux modifier le compilateur, corriger des problèmes dedans ou ajouter de nouvelles fonctionnalités. Tu peux donc faire un fork de F# (et ton fork peut être un logiciel libre, propriétaire ou commercial si tu veux).

Concrètement, c'est intéressant sur plusieurs niveaux. Beaucoup de gens préfèrent utiliser des logiciels libres, ça peut donc les convaincre d'utiliser F# (la licence était un frein pour certains). F# pourra être diffusé plus facilement, notamment sur les distributions Linux, qui pourront le proposer sans avoir à passer par un site de Microsoft. Si un jour Microsoft fait des "bêtises" ou cesse le développement de F#, n'importe qui pourra poursuivre le développement, ce qui améliore la pérennité. Certaines fonctionnalités pourront être développées, même si elle ne suivent pas les intérêts de Microsoft (un portage pour la JVM par exemple). Si des entreprises ont des besoins spécifiques, elles pourront modifier le compilateur (pour Caml, je sais qu'une entreprise maintient sa propre version du compilateur... mais elle a dû payer pour ça). Enfin, ça peut aussi convaincre des universités à enseigner F#.

**Dim Me As New Idiot** · 05/11/2010, 13h46

Il y a quelque chose qui me turlupine dans son message :

After some discussion, we’ve decided to do this via a “code drop” model, where we make available versions of the compiler+library code logically matching each release of the F# language itself. In the F# team, releases of F# are matched to coincide with releases of Visual Studio itself: using this release cadence simplifies our development processes and gives clarity to language versioning. This means the code we are making available today is for the F# 2.0 language, released in April 2010, including the small changes for the MSI tools updates through November 2010. We expect to make matching code drops if/when service pack(s) of Visual Studio 2010 are released, though sometimes it may take a while for us to get that out the door.

En gros, d'après ce que je comprends, ils vont diffuser que des instantanés des sources du compilateur correspondant aux versions successives du compilateur (2.0, 3.0, etc...) ?