-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Bonjour. Une belle question, très difficile à répondre, que j'aurais aimé recevoir plus tôt. L'interpréteur marche correctement parce que il contient déjà un système de gestion automatique de la mémoire, c'est-à-dire le tracing garbage collector de OCaml : puisque il s'agit d'un système automatique vous n'avez pas remarqué sa présence, mais il est là (en fait il est aussi très complexe), et il fait du travail. Par exemple vous pouvez vérifier que le programme TrivialML suivant ne vas pas occuper toute la mémoire de votre ordinateur, même s'il construit un nombre illimité de couples : =================================================== val build_a_pair_and_loop : int -> int;; let build_a_pair_and_loop = lambda n : int . let useless : int * int = n, n in build_a_pair_and_loop (n + 1);; build_a_pair_and_loop 0 =================================================== Dans la partie 7 on vous demande d'écrire *votre* système de gestion de la mémoire, qui (voire la question 7.6) on pourrait utiliser dans TrivialML au lieu du garbage collector de OCaml. Ne faites pas de la confusion entre environnement et mémoire. J'essaie de vous faire comprendre la distinction entre deux niveaux : - - l'environnement est une structure mathématique, «une fonction», qui a aussi une implémentation dans l'interpréteur. - - la mémoire est le grand tableau de mots (c'est-à-dire nombres) dans votre ordinateur, qui vous pouvez affecter ; tous les objets sur lesquels vous travaillez lorsque vous écrivez des programmes dans n'importe quel langage sont encodés en mémoire. On vous demande, dans la question 7, de simuler la mémoire d'un ordinateur avec un module OCaml. La motivation et toujours la même : on utilise un langage fonctionnel, donc «proche de la mathématique», pour donner des spécifications exécutables. Ce dernier point est subtil, et vous n'êtes pas obligés de le comprendre. La représentation des environnements dans la mémoire de MemLL n'est demandé que dans la question 7.6 (et de façon implicite aussi) ; mais on peut facilement imaginer que l'environnement soit une structure de données aussi (par exemple une liste de couples), et que pourtant on ait besoin de gérer la création et la destruction de ses sous-structures ; pensez, par exemple, à l'environnement comme une liste de couples : il faudra détruire certaines couples de temps en temps ! Et une implémentation réaliste d'un langage fonctionnel probablement utiliserait «la même mémoire» pour les données et l'environnement. Très cordialement, On 01/29/2011 11:37 PM, Nejdet ALTINISIK wrote:
nous ne comprenons pas exactement les modules pour la gestion de la mémoire de la question 7.2 à 7.4. Nous comprenons comment implémenter à peu prés la solution, mais nous ne voyons pas son utilité. Par exemple, une chose vraiement étrange, nous avons environment défini dans envmodules.ml et utilisé dans les fichiers par la suite. Comme notre fichier a.out marche correctement, lors des appels de fonction, l'interpréteur reconnait les expression et renvoit les valeurs enregistrées dans environment (chaque fonction définie étant enregistrée dans environment - a moins que je me trompe) pour dire que notre syntaxe est correcte et pour renvoyer la réponse. Nos questions sont donc : - A quoi sert MemLL alors que tout marche correctement (Meme si une separation de la mémoire est présente dans tous les langages et toutes les machines du monde !) et quand est-il vraiment appelé ? - Comment est représenté environment dans cette mémoire à proprement parlé, ou encore comment il intéragit, ou encore environment n'est-il plus utile ?
Pardonnez-moi toutes ces questions, mais on a du mal à cerner cette partie du projet qui nous semble ambigue.
Cordialement.
- -- Luca Saiu http://www-lipn.univ-paris13.fr/~saiu GNU epsilon: http://www.gnu.org/software/epsilon Marionnet: http://www.marionnet.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1Gi+QACgkQvzOavibF0oaKWgCfQDDfVpBA4CkScV8Jmdt4YejE /tkAn0NfXCimsg7P6AYoVPHHTQx83qHZ =B43C -----END PGP SIGNATURE-----
participants (1)
-
Luca Saiu