Publicité
+ Répondre à la discussion
Page 5 sur 12 PremièrePremière 123456789 ... DernièreDernière
Affichage des résultats 81 à 100 sur 233
  1. #81
    Rédacteur/Modérateur

    Avatar de gorgonite
    Homme Profil pro Nicolas Vallée
    Ingénieur d'études
    Inscrit en
    décembre 2005
    Messages
    10 206
    Détails du profil
    Informations personnelles :
    Nom : Homme Nicolas Vallée
    Âge : 30
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur d'études
    Secteur : Transports

    Informations forums :
    Inscription : décembre 2005
    Messages : 10 206
    Points : 16 754
    Points
    16 754

    Par défaut

    Citation Envoyé par BigTotoro
    D'ailleurs pour Mac OS, est-ce que la couche graphique s'appuit sur Xwindow ou bien est-ce complètement différent?

    un peu des deux... par défaut non, mais X11 (donc certainement XWindow) est "activable" mais plus lent
    (enfin, si j'ai bien retenu... je n'ai pas programmé avec MacOS X, le MacOS 9 de ma prépa m'en a écoeuré à jamais )
    Evitez les MP pour les questions techniques... il y a des forums
    Contributions sur DVP : Mes Tutos | Mon Blog

  2. #82
    Expert Confirmé Sénior
    Avatar de Jedai
    Homme Profil pro
    Enseignant
    Inscrit en
    avril 2003
    Messages
    6 168
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Côte d'Or (Bourgogne)

    Informations professionnelles :
    Activité : Enseignant

    Informations forums :
    Inscription : avril 2003
    Messages : 6 168
    Points : 7 663
    Points
    7 663

    Par défaut

    Citation Envoyé par gorgonite
    un peu des deux... par défaut non, mais X11 (donc certainement XWindow) est "activable" mais plus lent
    (enfin, si j'ai bien retenu... je n'ai pas programmé avec MacOS X, le MacOS 9 de ma prépa m'en a écoeuré à jamais )
    Ne fait pas l'amalgame : MacOS "Classic" (avant X) n'a rien à voir avec MacOS X, MacOS X est basé sur un système BSD et est d'excellente qualité et un plaisir à utiliser en général pour les développeurs.

    --
    Jedaï

  3. #83
    Invité régulier
    Inscrit en
    juin 2006
    Messages
    6
    Détails du profil
    Informations personnelles :
    Âge : 46

    Informations forums :
    Inscription : juin 2006
    Messages : 6
    Points : 7
    Points
    7

    Par défaut

    Désolé, je ne suis pas très habitué de genre de forum évolué. Je ne connais que celui d'Anubis language. Et je viens de comprendre que MP veut dire "Mail Privé". C'est très évident lorsqu'on le sait.

  4. #84
    Futur Membre du Club
    Inscrit en
    septembre 2004
    Messages
    50
    Détails du profil
    Informations forums :
    Inscription : septembre 2004
    Messages : 50
    Points : 15
    Points
    15

    Par défaut

    Citation Envoyé par BigTotoro
    Bonjour à tous,

    Je suis David René, l'auteur des portages Windows, MIPS, BeOS, Zeta d'Anubis.
    Effectivement le portage ne pose aucun problème en ce qui concerne le compilateur écrit quasiment en ANSI C avec des touches de C++. Par contre en ce qui concerne la machine virtuelle, la problématique vient de la couche graphique du système hôte. Mais, avec un peu de patience, du café, du paracetamol c'est faisable.
    D'ailleurs pour Mac OS, est-ce que la couche graphique s'appuit sur Xwindow ou bien est-ce complètement différent?
    Parce que si c'est XWindow le portage devrait être presque une formalité.
    Par ailleurs, tout les candidats au portage d'Anubis sur différentes plate forme sont les bienvenues et peuvent soumettre leur candidature en m'envoyant un mail privé par (MP).
    Disons qu'XWindow est quasiment installé par défaut (au pire, il faut remettre le cd d'install d'OS X dans le lecteur), donc ne te casse pas, fait un portage pour XWindow sous Mac, ça suffira amplement :-)

  5. #85
    Inactif
    Inscrit en
    juillet 2005
    Messages
    1 958
    Détails du profil
    Informations personnelles :
    Âge : 49

    Informations forums :
    Inscription : juillet 2005
    Messages : 1 958
    Points : 2 133
    Points
    2 133

    Par défaut

    Citation Envoyé par BigTotoro
    [...]D'ailleurs pour Mac OS, est-ce que la couche graphique s'appuit sur Xwindow ou bien est-ce complètement différent? [...]
    La base est un système propre à Mac, mais il y a effectivement X11 qui est un xwindows. Xfig se compile très bien par exemple sous X11, de même qu'un grand nombre de logiciels pour Linux.

    À court terme c'est une bonne solution. À plus long terme, ça serait dommage de ne pas bénéficier de l'interface graphique de Mac.

  6. #86
    Membre éclairé

    Inscrit en
    août 2005
    Messages
    417
    Détails du profil
    Informations personnelles :
    Âge : 64

    Informations forums :
    Inscription : août 2005
    Messages : 417
    Points : 330
    Points
    330

    Par défaut

    On peut facilement se faire une idée de ce qui est nécessaire comme primitives (tant graphiques qu'autres) dans la machine virtuelle d'Anubis. Il suffit de consulter le fichier 'anubis/library/predefined.anubis', où elles sont toutes déclarées. Le symbole £avm permet d'écrire des instructions (et appels système) de ladite machine. On pourra voir qu'il n'y a pas des centaines de fonctions.

  7. #87
    Rédacteur
    Avatar de SpiceGuid
    Homme Profil pro Damien Guichard
    Inscrit en
    juin 2007
    Messages
    1 574
    Détails du profil
    Informations personnelles :
    Nom : Homme Damien Guichard
    Localisation : France, Loire (Rhône Alpes)

    Informations forums :
    Inscription : juin 2007
    Messages : 1 574
    Points : 2 449
    Points
    2 449

    Par défaut

    Quel est le type de machine abstraite de Anubis 1.7: SECD, CAM, FAM, ZAM ?

    Je recommande la lecture de ce document:

    http://pauillac.inria.fr/~xleroy/talks/zam-kazam05.pdf

    La phrase clé étant: "Curried function application is costly in the CAM".

  8. #88
    Membre éclairé

    Inscrit en
    août 2005
    Messages
    417
    Détails du profil
    Informations personnelles :
    Âge : 64

    Informations forums :
    Inscription : août 2005
    Messages : 417
    Points : 330
    Points
    330

    Par défaut

    Citation Envoyé par SpiceGuid
    La phrase clé étant: "Curried function application is costly in the CAM".
    Effectivement, et cela tient au fait que pour une fonction de n arguments, la CAM construit n fermetures enchaînées. C'est bien sûr une conséquence du fait que les fonctions sont systématiquement currifiées.

    Par ailleurs, il se trouve que je connais très bien la CAM, pour la raison que je l'ai vue naître à Paris 7, et que j'ai participé à sa diffusion. En effet, quand en 1984 j'ai passé ma thèse d'état en topologie algébrique, j'ai demandé à Guy Cousineau un sujet de deuxième thèse (obligatoire pour une thèse d'état), et il m'a proposé ... la CAM, qu'il venait de créer avec Pierre-Louis Curien. Par la suite, c'est moi qui l'ait fait connaître aux logiciens de Paris 7, lors d'un exposé du séminaire de logique Krivine-Girard. Quelques jours auparavant, je rencontre Jean-Louis Krivine dans une discussion, et comme il ne manque pas d'humour, il me dit: alors au prochain séminaire, tu nous refiles la CAM... Voila pour la petite histoire.

    Par contre, je ne connaissais pas les autres machines citées par SpiceGuid. Je me suis un peu documenté pour voir de quoi il en retourne, au moins en ce qui concerne la ZAM, et la ZAM2.

    Pour ce qui est de la machine virtuelle d'Anubis, crée en 2000, donc longtemps après ma rencontre avec la CAM, j'ai eu le temps de repenser la chose et de faire quelques optimisations. Le résultat semble être assez proche de la ZAM2. Précisément, voici comment ça marche.

    Le compilateur Anubis transforme un terme (en fait une lambda-expression) de la forme:
    Code :
    1
    2
    (T1 x1,..., Tn xn) |-> E
    en un bout de code qui fabrique une seule fermeture. Cette fermeture est construite (à l'exécution donc) par allocation d'un seul segment de mémoire, qui contient les informations suivantes:
    • un compteur pour le garbage-collector par incrément-décrément,
    • un pointeur sur le code de la fonction,
    • un pointeur sur le code de garbage-collector spécifique à la fermeture construite (ce pointeur est nécessaire, car ce code varie d'une fermeture à l'autre, même si les fonctions qu'elles représentent sont de même type),
    • un micro-contexte c'est à dire un tableau de données (et non pas un enchaînement par des pointeurs) qui sont les valeurs des variables qui apparaîssent libres dans la lambda-expression et d'elles seules (donc comme dans la ZAM2).

    Par contraste, les fermetures de la CAM embarquent tout le contexte, y compris ce dont elles ne se servent pas.

    En fait, la principale des raisons pour lequelles je voulais absolument n'embarquer dans le micro-contexte que les valeurs des variables vraiment utilisées par la fonction n'était pas une affaire de performances, mais une affaire de garbage-collector. En effet, en Anubis (mais pas seulement en Anubis), quand un fichier, une connexion réseau, une base de données, etc... est ouverte, on n'a jamais à se préoccuper de la fermer. D'ailleurs, il n'y a pas d'instruction pour cela. C'est le garbage-collector qui ferme lui-même ces objets en même temps qu'il désalloue le segment qui les contient quand le compteur de référence tombe à zéro.

    Ainsi donc, supposons que le contexte local contienne un tel objet (disons une connexion réseau), et que dans ce contexte on fabrique une fonction à la volée qui ne fait pas référence à cette connexion mais qui survit beaucoup plus longtemps que la connexion. Si tout le contexte était embarqué, la connexion ne serait jamais fermée avant que cette fermeture elle-même ne disparaîsse, ce qui évidemment pose un gros problème, car les deux choses (la connexion et la fonction) sont sans rapport l'une avec l'autre, et des connexions pourraient rester beaucoup trop longtemps ouvertes, voire indéfiniment.

    Bien entendu, ce système a nécessité une duplication des instructions peek qui permettent d'aller chercher une valeur dans la pile à une profondeur donnée, car ces valeurs sont soit directement dans la pile, soit dans le micro contexte d'une fermeture qui se trouve elle même dans la pile. Pour une valeur se trouvant dans un micro-contexte, il faut deux nombres en opérandes du peek (qui dans ce cas s'appelle d'ailleurs micro_peek), un pour la profondeur dans la pile, et l'autre pour l'offset dans le micro-contexte.

    On peut d'ailleurs constater tout cela de visu. Il suffit en effet de compiler un source Anubis avec l'option (non documentée) -sc (sc pour 'symbolic code'). Le compilateur produit alors pour chaque module un fichier d'extension .sc qui est une version lisible du fichier d'extension .adm correspondant. Quand le module fabrique des fermetures, on a des représentation de la pile qui montrent un micro-contexte. Les profondeurs de piles sont numérotées avec des entiers et les positions des valeurs des micro-contextes sont numérotées avec deux entiers séparés par un point, comme dans l'exemple suivant:

    D'abord un petit source Anubis:
    Code :
    1
    2
    3
    4
    5
    6
    7
    8
    global define One
       essai
         (
           List(String) args
         ) =
       with prefix = "ga",
       forget(map((String x) |-> print(prefix+x+"\n"),["bu","zo","meu"])).
    Voici ce que donne la compilation et l'exécution:

    Code :
    1
    2
    3
    4
    5
    6
    7
    8
    alp@alp-laptop:~$ anubis essai.anubis
    Constructing module '/home/alp/my_anubis/modules/essai.adm' ... Done.
    alp@alp-laptop:~$ anbexec essai
    gabu
    gazo
    gameu
    alp@alp-laptop:~$
    et voici un extrait du fichier .sc:

    Code :
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
             |         * * * closure code * * *
             |
         253 |  label 49
         253 |    check_stack 8
         258 |    push_addr 47
         263 |    string 4                         ("
    ")
         274 |    push
         275 |    peek "x" 2
         280 |    copy_ptr
         281 |    push
             |       ;--- stack ------------------------
             |       ;   0                            String
             |       ;   1                            String
             |       ;   2                            (return address)
             |       ;   3     x                      String
             |       ;   4.0   prefix                 String
             |       ;   5                            (return address)
             |       ;----------------------------------
         282 |    strconcat
         285 |    del_stack_ptr 0
         290 |    del_stack_ptr 0
         295 |    push
         296 |    micro_peek "prefix" 3 0
        ... etc ...
    Comme on peut le voir, la représentation qui est donnée de la pile contient la profondeur 4.0, qui signifie que la fermeture se trouve à la profondeur 4 dans la pile, et que la valeur du symbole 'prefix' qui est utilisé par la fonction est à l'offset 0 dans le micro-contexte.

    Un peu plus loin, on voit une utilisation de l'instruction 'micro_peek', dont l'opérande "prefix" n'existe en fait pas (il est juste pour la décoration du fichier .sc) et dont les deux autres opérandes sont la profondeur dans la pile et l'offset de 'prefix' dans le micro-contexte (entre temps, la profondeur de la fermeture dans la pile a changé: elle est passée de 4 à 3).

    Je compte conserver ces principes pour Anubis 2 (ça marche très bien et il semble que c'est assez optimal). Toutefois, si vous avez des idées pour optimiser encore, je suis preneur bien sûr...

    Une dernière remarque: ceci ne remet pas en cause le rôle joué par les catégories, qui peuvent tout aussi bien modéliser ce système que la CAM.

  9. #89
    Rédacteur/Modérateur

    Avatar de gorgonite
    Homme Profil pro Nicolas Vallée
    Ingénieur d'études
    Inscrit en
    décembre 2005
    Messages
    10 206
    Détails du profil
    Informations personnelles :
    Nom : Homme Nicolas Vallée
    Âge : 30
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur d'études
    Secteur : Transports

    Informations forums :
    Inscription : décembre 2005
    Messages : 10 206
    Points : 16 754
    Points
    16 754

    Par défaut

    En ce qui concerne les fonctions curryfiées dans la ZAM, il me semble qu'il y a une optimisation effectuée "après coup" pour supprimer par le mécanisme de "tail-call elimination"

    pour ce qui est de la CAM, il me semble que l'optimisation consistant à ne pas systématiquement embarquer l'environnement complet a également été effectuée... si j'ai bien suivi le cours que nous a fait Michel Mauny
    Evitez les MP pour les questions techniques... il y a des forums
    Contributions sur DVP : Mes Tutos | Mon Blog

  10. #90
    Membre Expert
    Avatar de InOCamlWeTrust
    Inscrit en
    septembre 2006
    Messages
    1 036
    Détails du profil
    Informations forums :
    Inscription : septembre 2006
    Messages : 1 036
    Points : 1 129
    Points
    1 129

    Par défaut

    Si je me souviens bien, les fermetures ne sont plus chaînées dans la machine virtuelle de OCaml : d'ailleurs, la CAM, c'est du passé.

    Citation Envoyé par gorgonite
    En ce qui concerne les fonctions curryfiées dans la ZAM, il me semble qu'il y a une optimisation effectuée "après coup" pour supprimer par le mécanisme de "tail-call elimination"
    Oui, bien-sûr, les appels récursifs terminaux sont optimisés : les fonctions récursives terminales sont transformées en programmes itératifs, avec boucle.

  11. #91
    Rédacteur
    Avatar de SpiceGuid
    Homme Profil pro Damien Guichard
    Inscrit en
    juin 2007
    Messages
    1 574
    Détails du profil
    Informations personnelles :
    Nom : Homme Damien Guichard
    Localisation : France, Loire (Rhône Alpes)

    Informations forums :
    Inscription : juin 2007
    Messages : 1 574
    Points : 2 449
    Points
    2 449

    Par défaut

    La SECD, CAM et FAM sont toutes dépassées (elles créent toutes trop de fermetures intermédiaires pour les appels de fonction curryfiées), dans les faits il n'existe plus que deux VM:
    * la ZAM pour les langages strictes (ML,Anubis)
    * la G-machine pour les langages paresseux (Miranda,Haskell)

    Hors sujet: Microsoft est à la fois un membre du consortium OCaml et l'employeur de Simon Peyton Jones (l'architecte de la G-machine). Est-ce que Simon P. Jones est impliqué dans F# ?

    Enfin les compilateurs Scheme préfèrent la compilation CPS (Continuation Passing Style).

    En tout cas, il est impressionnant que Anubis soit aussi près d'être compétitif sur tous les fronts, malgré le peu de ressources humaines dont le projet dispose (si on compare à l'INRIA ou à Microsoft).

  12. #92
    Rédacteur/Modérateur

    Avatar de gorgonite
    Homme Profil pro Nicolas Vallée
    Ingénieur d'études
    Inscrit en
    décembre 2005
    Messages
    10 206
    Détails du profil
    Informations personnelles :
    Nom : Homme Nicolas Vallée
    Âge : 30
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur d'études
    Secteur : Transports

    Informations forums :
    Inscription : décembre 2005
    Messages : 10 206
    Points : 16 754
    Points
    16 754

    Par défaut

    Citation Envoyé par SpiceGuid
    Hors sujet: Microsoft est à la fois un membre du consortium OCaml et l'employeur de Simon Peyton Jones (l'architecte de la G-machine). Est-ce que Simon P. Jones est impliqué dans F# ?
    a priori non... http://research.microsoft.com/ero/IC...6SummerSchool/


    Citation Envoyé par SpiceGuid
    Enfin les compilateurs Scheme préfèrent la compilation CPS (Continuation Passing Style).
    franchement, sur un langage typé "en grande partie dynamiquement", et pour l'interprétation, c'est rudement efficace...


    Citation Envoyé par SpiceGuid
    En tout cas, il est impressionnant que Anubis soit aussi près d'être compétitif sur tous les fronts, malgré le peu de ressources humaines dont le projet dispose (si on compare à l'INRIA ou à Microsoft).

    je ne peux pas juger... je ne l'ai pas encore testé
    la remarque que je ferai sera plus au niveau fonctionnalités... a-t-on autant de fonctionnalités, et de possibilités d'interfacer des librairies écrites dans d'autres langages (très chiantes à refaire, ou extrêment performantes) ?
    il faut quand même se dire que les langages ayant un grand pouvoir expressif le payent parfois aux niveaux des optimisations qu'il est possible de leur appliquer (mais c'est un autre débat)
    Evitez les MP pour les questions techniques... il y a des forums
    Contributions sur DVP : Mes Tutos | Mon Blog

  13. #93
    LLB
    LLB est déconnecté
    Membre Expert
    Inscrit en
    mars 2002
    Messages
    962
    Détails du profil
    Informations forums :
    Inscription : mars 2002
    Messages : 962
    Points : 1 128
    Points
    1 128

    Par défaut

    Citation Envoyé par SpiceGuid
    Hors sujet: Microsoft est à la fois un membre du consortium OCaml et l'employeur de Simon Peyton Jones (l'architecte de la G-machine). Est-ce que Simon P. Jones est impliqué dans F# ?
    Non. Il bosse plutôt sur Haskell et le Glasgow Haskell Compiler (cf http://research.microsoft.com/~simonpj/#who).

    Citation Envoyé par SpiceGuid
    En tout cas, il est impressionnant que Anubis soit aussi près d'être compétitif sur tous les fronts, malgré le peu de ressources humaines dont le projet dispose (si on compare à l'INRIA ou à Microsoft).
    L'équipe de F# est relativement petite également (ce n'est pas un produit Microsoft, c'est un sujet de recherche) :
    F# is developed and maintained by Don Syme and James Margetson. Contributors have included Cedric Fournet, Can Erten, Greg Neverov, Tomas Petricek, Byron Cook, Simon Marlow and Georges Gonthier.

  14. #94
    Rédacteur/Modérateur

    Avatar de gorgonite
    Homme Profil pro Nicolas Vallée
    Ingénieur d'études
    Inscrit en
    décembre 2005
    Messages
    10 206
    Détails du profil
    Informations personnelles :
    Nom : Homme Nicolas Vallée
    Âge : 30
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur d'études
    Secteur : Transports

    Informations forums :
    Inscription : décembre 2005
    Messages : 10 206
    Points : 16 754
    Points
    16 754

    Par défaut

    au passage, je ne sais pas si l'équipe qui développe le "coeur" de OCaml est si nombreuse que cela... http://gallium.inria.fr/

    sachant que dans cette équipe, il y a aussi du monde qui bosse sur les projets annexes comme menhir ou cduce


    certes, il y a plein de monde qui utilisent ocaml à l'inria, mais cela ne "compte" pas, sinon on peut mettre tous les développeurs .Net dans les contributeurs de F# (ça s'interface quoi )
    Evitez les MP pour les questions techniques... il y a des forums
    Contributions sur DVP : Mes Tutos | Mon Blog

  15. #95
    Rédacteur
    Avatar de SpiceGuid
    Homme Profil pro Damien Guichard
    Inscrit en
    juin 2007
    Messages
    1 574
    Détails du profil
    Informations personnelles :
    Nom : Homme Damien Guichard
    Localisation : France, Loire (Rhône Alpes)

    Informations forums :
    Inscription : juin 2007
    Messages : 1 574
    Points : 2 449
    Points
    2 449

    Par défaut

    Citation Envoyé par DrTopos
    un micro-contexte c'est à dire un tableau de données (et non pas un enchaînement par des pointeurs) qui sont les valeurs des variables qui apparaîssent libres dans la lambda-expression et d'elles seules (donc comme dans la ZAM2).

    ...

    Bien entendu, ce système a nécessité une duplication des instructions peek qui permettent d'aller chercher une valeur dans la pile à une profondeur donnée, car ces valeurs sont soit directement dans la pile, soit dans le micro contexte d'une fermeture qui se trouve elle même dans la pile. Pour une valeur se trouvant dans un micro-contexte, il faut deux nombres en opérandes du peek (qui dans ce cas s'appelle d'ailleurs micro_peek), un pour la profondeur dans la pile, et l'autre pour l'offset dans le micro-contexte.
    Simon Peyton Jones propose une autre approche, la transformation dite Johnsson-lambda-lifting, en pratique, après cette transformation, toutes les fonctions ne contiennent plus que des variables liées, il n'y a plus besoin d'aucun micro-contexte. Pourquoi cette approche n'est utilisée que pour compiler des langages paresseux ?

    Cette transformation est très bien décrite dans le document de Peyton Jones sur la G-machine.

  16. #96
    Membre éclairé

    Inscrit en
    août 2005
    Messages
    417
    Détails du profil
    Informations personnelles :
    Âge : 64

    Informations forums :
    Inscription : août 2005
    Messages : 417
    Points : 330
    Points
    330

    Par défaut

    Bonjour à tous.

    Quelques remarques inspirées par les posts précédents.

    La CAM est sans doute périmée (sur le plan des performances, et aussi par le fait que les fermetures embarquent l'intégralité du contexte), mais il ne faut pas sous-estimer la valeur des idées de Pierre-Louis Curien sur le plan formel. Ce qui était particulièrement enthousiasmant dans la CAM est le traduction faite par Curien des symboles du formalisme des catégories cartésiennes fermées en instructions machine. Ce procédé est une façon de prouver la correction de la machine. En plus c'est très joli.

    La machine virtuelle d'Anubis 1 n'est pas la ZAM ni la ZAM2. C'est une machine originale, que j'ai créée sans connaître les ZAMs. Il se trouve qu'il y a quelques ressemblances sur certains points, mais c'est tout. D'ailleurs, d'une manière générale, je n'imite personne. Ce n'est pas dans ma façon de travailler. Je préfère réfléchir et selectionner les solutions qui me parraissent les meilleures (quitte à réinventer la poudre de temps en temps). De ce point de vue d'ailleurs, je trouve qu'une entreprise comme MicroSoft, qui se prétend à la pointe de la recherche, ne trouve rien de plus original que de pomper Caml mot à mot pour créer F#. Manque total d'imagination....

  17. #97
    LLB
    LLB est déconnecté
    Membre Expert
    Inscrit en
    mars 2002
    Messages
    962
    Détails du profil
    Informations forums :
    Inscription : mars 2002
    Messages : 962
    Points : 1 128
    Points
    1 128

    Par défaut

    Citation Envoyé par DrTopos
    De ce point de vue d'ailleurs, je trouve qu'une entreprise comme MicroSoft, qui se prétend à la pointe de la recherche, ne trouve rien de plus original que de pomper Caml mot à mot pour créer F#. Manque total d'imagination....
    Ce n'est pas tout à fait ça... F# est un sujet de recherche qui a beaucoup aidé à intégrer la programmation fonctionnelle dans .NET : d'une part, via des projets comme ILX (qui simplifie la compilation de langages fonctionnels en CIL), et d'autre part en testant des solutions qui sont ensuite reprises dans C# (cf entre autres les ajouts dans C# 3).

    Ils ont choisi de se baser sur Caml plutôt que de créer un langage de toute pièce. C'est certes discutable, mais ça offre beaucoup d'avantages : le bootstrap est super simple, vu que F# a d'abord été écrit en Caml ; l'ensemble des bibliothèques Caml peut être réutilisé beaucoup plus facilement ; pour les utilisateurs, c'est aussi plus simple que d'apprendre un tout nouveau langage. Donc, plutôt qu'un manque d'imagination, c'est surtout une question d'interopérabilité (et on ne va pas reprocher ça à Microsoft :p) avec Caml et .NET en même temps.

    Par ailleurs, ce n'est absolument pas une simple copie. Tout le système OO est différent, et il y a pas mal de différences et d'ajouts (que j'ai déjà cités plusieurs fois dans le forum). Le langage progresse vite et des innovations sont faites. Par exemple, l'implémentation des active patterns (pattern matching extensible) est extrêmement intéressante. En ce moment même, ils ajoutent des opérateurs de slicing (e.g. let s = "abcdef" in s.[2,4]) qui peuvent surchargés et étendus pour n'importe quel type (en lecture, ou en assignation (s.[2,3] <- s.[4,5])) ; ils réfléchissent aussi à l'intégration de mixins dans le langage. Si on a pu leur reprocher un manque d'imagination au début, ce n'est plus le cas depuis un an.

    Comme je l'ai dit aussi, ils ne sont que 2 à concevoir le langage (plus quelques personnes qui aident ponctuellement), et F# n'a pas pour but de gagner de l'argent. Je trouve finalement le résultat plus que correct et n'ai jamais senti ça comme un manque d'imagination.

  18. #98
    Membre éclairé

    Inscrit en
    août 2005
    Messages
    417
    Détails du profil
    Informations personnelles :
    Âge : 64

    Informations forums :
    Inscription : août 2005
    Messages : 417
    Points : 330
    Points
    330

    Par défaut

    @LLB Il est clair que tu connais F# beaucoup mieux que moi, et que as raison. Malgré cela, j'ai été interpellé par le fait que le 'core language' F# est pratiquement Caml à la virgule près, sans pourtant en porter le nom (ou un nom dérivé de Caml). Caml est-il seulement cité dans les documents MicroSoft ? Je trouve cela un peu choquant. Je ne sais pas ce qu'en pensent les gens de l'équipe Caml.

    Par contre, compte tenu de la visibilité de MicroSoft, si cela pouvait faire monter le pourcentage de développeurs (et de décideurs) utilisant les langages fonctionnels, ce serait une bonne chose. Il valait peut-être mieux d'ailleurs pour MicroSoft, choisir un langage éprouvé comme Caml, plutôt que de tenter d'en créer un nouveau (sur quelles bases d'ailleurs). C'est de bonne politique.

  19. #99
    LLB
    LLB est déconnecté
    Membre Expert
    Inscrit en
    mars 2002
    Messages
    962
    Détails du profil
    Informations forums :
    Inscription : mars 2002
    Messages : 962
    Points : 1 128
    Points
    1 128

    Par défaut

    Citation Envoyé par DrTopos
    @LLB Il est clair que tu connais F# beaucoup mieux que moi, et que as raison. Malgré cela, j'ai été interpellé par le fait que le 'core language' F# est pratiquement Caml à la virgule près, sans pourtant en porter le nom (ou un nom dérivé de Caml). Caml est-il seulement cité dans les documents MicroSoft ? Je trouve cela un peu choquant. Je ne sais pas ce qu'en pensent les gens de l'équipe Caml.
    Microsoft fait partie du consortium Caml et (je crois) a donné de l'argent pour Caml. Il me semble que les relations entre les deux équipes soient assez bonnes, Xavier Leroy (concepteur de Caml) est d'ailleurs cité dans les remerciements :
    Although F# is a complete re-implementation of an OCaml-like language, a special thanks go to the OCaml team, in particular Xavier Leroy, who agreed that a 'Caml.NET' was a good thing to do suggested I experiment with language design instead of just implementing OCaml exactly, and to Jacques Garrigue who gave some helpful positive feedback.
    Et aussi : http://caml.inria.fr/pub/ml-archives...2123ca.fr.html

    Ca me semble assez clair. Je comprends aussi tes craintes, j'ai eu les mêmes quand j'ai découvert F#. Mais force a été de constater que j'ai été très agréablement surpris et que Microsoft est remonté dans mon estime grâce à ça. J'utilise quotidiennement F# depuis 6 mois, je suis en contact régulier avec Don Syme (son concepteur) et je dois reconnaitre qu'il fait du bon travail (tout comme les gens de l'INRIA, ou comme toi, de ce que j'ai vu). C'est assez loin de l'image de Microsoft que j'avais au départ.

    Citation Envoyé par DrTopos
    Par contre, compte tenu de la visibilité de MicroSoft, si cela pouvait faire monter le pourcentage de développeurs (et de décideurs) utilisant les langages fonctionnels, ce serait une bonne chose.
    Oui, c'est ce que j'espère aussi. Je pense que F# est l'un des langages fonctionnels les plus accessibles pour un débutant (si on copie-colle une fonction C# en F#, il y a très peu de modifications à faire pour que cela fonctionne) et j'espère que cela va permettre de développer la programmation fonctionnelle aussi bien auprès des débutants que des entreprises.

  20. #100
    Membre éclairé

    Inscrit en
    août 2005
    Messages
    417
    Détails du profil
    Informations personnelles :
    Âge : 64

    Informations forums :
    Inscription : août 2005
    Messages : 417
    Points : 330
    Points
    330

    Par défaut

    Citation Envoyé par LLB
    Ca me semble assez clair. Je comprends aussi tes craintes, j'ai eu les mêmes quand j'ai découvert F#. Mais force a été de constater que j'ai été très agréablement surpris et que Microsoft est remonté dans mon estime grâce à ça.
    Cela a été mon cas également. J'ai été agréablement surpris par MS. Jusque là j'avais surtout cette image négative d'un Windows instable, nid à virus, obligation de réacheter Windows avec chaque nouveau micro (j'utilise Linux), mépris de tout ce qui n'est pas dans le monde Windows, etc... ce qui évidemment donne une très mauvaise image de MS.

Liens sociaux

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •