Envoyé par BigTotoro
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)
Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
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.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
--
Jedaï
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.
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 :-)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).
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.
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.
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".
Du même auteur: mon projet, le dernier article publié, le blog dvp et le jeu vidéo.
Avant de poser une question je lis les règles du forum.
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:
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:
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
- 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:
Voici ce que donne la compilation et l'exécution:
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
3
4
5
6
7
8global define One essai ( List(String) args ) = with prefix = "ga", forget(map((String x) |-> print(prefix+x+"\n"),["bu","zo","meu"])).
et voici un extrait du fichier .sc:
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
3
4
5
6
7
8
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.
Code : Sélectionner tout - Visualiser dans une fenêtre à part
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 ...
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.
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
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é.
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.
When Colt produced the first practical repeating handgun, it gave rise to the saying God created men, but Colt made them equal.
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).
Du même auteur: mon projet, le dernier article publié, le blog dvp et le jeu vidéo.
Avant de poser une question je lis les règles du forum.
a priori non... http://research.microsoft.com/ero/IC...6SummerSchool/
franchement, sur un langage typé "en grande partie dynamiquement", et pour l'interprétation, c'est rudement efficace...
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)
Non. Il bosse plutôt sur Haskell et le Glasgow Haskell Compiler (cf http://research.microsoft.com/~simonpj/#who).
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.
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
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.
Du même auteur: mon projet, le dernier article publié, le blog dvp et le jeu vidéo.
Avant de poser une question je lis les règles du forum.
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.
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.
@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.
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 :
Et aussi : http://caml.inria.fr/pub/ml-archives...2123ca.fr.htmlAlthough 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.
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.
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.
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.
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager