Tranform src/TODO into a .org file (cf emacs org-mode).

src/TODO → src/TODO.org

 
-*********************************************************************
-*********************************************************************
-*** questions pour Pascal
-=========================
+
+* Questions pour Pascal
+=====================
 
 cf fichier QUESTION pour les question d'ordre plus général de choix de language
 (putot que d'implémenation).
 
 
-* dans le generateur de lic, comment imprimer le nom des packages ?
+** dans le generateur de lic, comment imprimer le nom des packages ?
  - Pack::toto -> pas du vieux lustre (donc pas reentrant)
  - Pack__toto -> name clash (si un ident local s'appelle comme ca)
  - _Pack__toto -> pas beau, rend lus2lic pas idempotent
 
 
-* slice_info_eff width = size ? Le commentaire dit 
+** slice_info_eff width = size ? Le commentaire dit 
  	S[i] = A[first + i*step] pour i = 0 .. width
 mais j'ai l'impression que ce devrait etre 
  	S[i] = A[first + i*step] pour i = 0 .. (width-1)
@@ -22,15 +21,15 @@ cad
  	S[i] = A[first + i*step] pour i = 0 .. (size-1)
 
 
-* Pour l'evaluation statique de l'egalité, j'ai pas fait pareil...
-grosso-modo, je teste si 'a=b' alors Pascal deconstruit plus finement
-le a  et le b. Mais j'ai  l'impression que ca revient  au meme. Ai-je
-raté un truc ? -> cf predefEvalConst.ml
+** Pour l'evaluation statique de l'egalité, j'ai pas fait pareil...
+   grosso-modo, je teste si 'a=b' alors Pascal deconstruit plus finement
+   le a  et le b. Mais j'ai  l'impression que ca revient  au meme. Ai-je
+   raté un truc ? -> cf predefEvalConst.ml
 
-* autoriser les  alias sur  "nor" et "#"  ? (ca compliquerait  les choses
+** autoriser les  alias sur  "nor" et "#"  ? (ca compliquerait  les choses
   pour bien peu... La difficulté étant du à l'arité variable de ces operateurs).
 
-* maintenant que je peux definir des trucs du genre
+** maintenant que je peux definir des trucs du genre
       x = map<<+;3>>
   ai-je encore besoin de Lustre::plus et consort ??? 
   bien que
@@ -47,29 +46,29 @@ rat
  pas d'en créer un avec ce nom...
  
 
-* au sujet des pragma:
+** au sujet des pragma:
  
 J'ai associé les pragma aux identificateurs, et seulement à eux. Est-ce suffisant ?
 
 
-* autoriser les noeuds (ou fonction) sans corps sans avoir a préciser
+** autoriser les noeuds (ou fonction) sans corps sans avoir a préciser
 "extern" ?
 
-* accepter les tuples multi-horloges ? ca parait logique, a partir du
+** accepter les tuples multi-horloges ? ca parait logique, a partir du
   moment où on accepte les noeuds multi-horloges. De même, la " -> "
   devrait être multi-horloge également. Et peut-etre d'autres encore...
 
-* soc = synchronous object component, c'est pas mieux comme nom ?
+** soc = synchronous object component, c'est pas mieux comme nom ?
 
-* Avec Marc, on pourrait aussi se synchroniser au niveau du lic.
+** Avec Marc, on pourrait aussi se synchroniser au niveau du lic.
 Mais du coup de travail de JB part à la poubelle...
 
-* En lic, dois-je generer lustre::ilt ou bien Lustre::lt ?
+** En lic, dois-je generer lustre::ilt ou bien Lustre::lt ?
 Générer lustre::ilt n'est pas tres compliqué, mais ca m'obliqe 
 à rajouter un LTI_n, LTR_n, etc., ce qui est un peu pénible
 et probablement géré à terme au niveau du lic.
 
-* dependance checking (lic2loc le fait ; faut-il le refaire ici ? )
+** dependance checking (lic2loc le fait ; faut-il le refaire ici ? )
 ex : 
   a=b;
   b=a;
@@ -78,15 +77,13 @@ cf
    test/should_fail/semantics/def.lus
    test/should_fail/semantics/piege.lus
 
-*********************************************************************
-*********************************************************************
-*** questions pour bibi
+* Questions pour bibi
 
-* EvalClock.var_clock_to_base (l200): c'est pas ca qu'il faut faire. 
+** EvalClock.var_clock_to_base (l200): c'est pas ca qu'il faut faire. 
   en effet, si on 1+1+a when c, ca risque de ne pas marcher.
 
 
-o Lazycompiler.solve_x_idref 
+** Lazycompiler.solve_x_idref 
 
  Comment  se faisse  que  je n'ai  pas  besoin de  me  servir de  cet
 x_info ?????  En fait, je devrais  le passer en  argument de x_check,
@@ -102,80 +99,75 @@ lazycompiler.ml:
   Simplify  a  little  bit  a  couple  of  functions  (avoiding  code
   duplication basically). 
 
+** Ident.idref : a remettre dans SyntaxTree ? 
+en  tout  cas,  je  devrais  m'en  etre completement  debarassé  au  niveau  du
+compiledData, et ca n'est pas le cas pour l'instant... cf [solve_ident]
 
 
-* Ident.idref : a remettre dans SyntaxTree ? en tout cas, je devrais
-m'en etre completement debarassé au niveau du compiledData, et ca
-n'est pas le cas pour l'instant... cf  [solve_ident]
-
-
-* accepter les expressions du style "b when not(a)" ? 
+** accepter les expressions du style "b when not(a)" ? 
   ou bien rajouter un mot clef "whenot" comme Marc?
 
-* un noeud  sans memoire  pourra etre déclaré  comme "node"  ou comme
+** Un noeud  sans memoire  pourra etre déclaré  comme "node"  ou comme
 "function" que si l'option -v4-compat est donnée ?
 
-* rejeter les expressions du style "a when a" ?
+** rejeter les expressions du style "a when a" ?
+
+* A faire
+** 3) pour le ec (specifiquement) le nommage  systematique avec  "nom du pack"
+(donc du fichier) en prefixe est un peu lourd,
+ en tout cas pas compatible avec ce que faisait pollux.
+ Il pourrait y avoir une option en plus du genre "-no-pack-prefix" ?
 
------------------------------------------------------------------------
------------------------------------------------------------------------
------------------------------------------------------------------------
-A faire
 
-* Attacher l'horloge des expressions aux expressions elle-meme,
-plutot que d'utiliser une hashtbl (comme pour le type).
+** Attacher l'horloge des expressions aux expressions elle-meme,
+   plutot que d'utiliser une hashtbl (comme pour le type).
 
-* pourquoi Eff.true_type_of_const n'est plus utiliser et qu'aucun des tests
+** pourquoi Eff.true_type_of_const n'est plus utiliser et qu'aucun des tests
 de non reg ne semblent avoir echouer ?
 
-* Ne pas  générer de  "current", "->", "pre"  (i.e., les  traduire en
+** Ne pas  générer de  "current", "->", "pre"  (i.e., les  traduire en
   termes de "merge" et "fby").
       
-* rajouter "mirror"?
+** rajouter "mirror"?
 
-* --help devrait  retourner la liste des  operateurs predefinis, avec
+** --help devrait  retourner la liste des  operateurs predefinis, avec
     leur type
 
-* Verifier que les fonctions sont des fonctions etc. 
+** Verifier que les fonctions sont des fonctions etc. 
 
-* verifier  qu'il n'est  pas nécessaire  de verifier  que les  gens ne
+** verifier  qu'il n'est  pas nécessaire  de verifier  que les  gens ne
   nomment pas leur package Lustre...
 
-* Dans Eff.const, le variant Int_const_eff devrait etre parametre par
+** Dans Eff.const, le variant Int_const_eff devrait etre parametre par
 un string, pas par un entier
 
-* le merge
+** le merge
 
-* traduire les enum (en mode --expand-enums) proprement, et pas en patchant
+** Traduire les enum (en mode --expand-enums) proprement, et pas en patchant
 LicDump comme actuellement. Car sinon, c'est pas facile de generer du
 code pour les horloges enumerés en mode -lv4.
 
 -----------------------------------------------------------------------
------------------------------------------------------------------------
------------------------------------------------------------------------
-Divers
+* Divers
 
-* patcher le mode emacs
+** patcher le mode emacs
 	- rajouter modele, package, etc.
 	- l'indentation est vraiment à chier
 
-
-* implementer une option --old-style-syntax pour faire quelque chose des trucs
+** implementer une option --old-style-syntax pour faire quelque chose des trucs
  du genre "[int,int]" voire meme "[int,real]" qui ne sont plus autorisé, mais à
  qui on pourrait donner du sens via des tableaux et des structures factices
 
 
------------------------------------------------------------------------
------------------------------------------------------------------------
 -----------------------------------------------------------------------
 * Manuel
 
-- finir de rédiger le manuel
-- verifier que j'y parle bien de la priorite des operateurs
-- verifier que chacun des exemples du repertoire "should_fail" à une
+** finir de rédiger le manuel
+** verifier que j'y parle bien de la priorite des operateurs
+** verifier que chacun des exemples du repertoire "should_fail" à une
 correspondance dans le manuel, et reciproquement...
 
-- Dans  la   doc,  distinguer  2   sortes  de  polymorphismes   :  le
+** Dans  la   doc,  distinguer  2   sortes  de  polymorphismes   :  le
 polymorphisme  faible,  et le  polymorphisme  fort,  qui accepte  les
 tuples! 
 
@@ -185,28 +177,26 @@ les operateurs polymorphes au sens fort sont : fby, ->, current, pre, ite
 En effet, on ne peut pas  ecrire (1,2) > (3,4) (enfin pour l'instant,
 mais est-ce souhaitable ?)
 
------------------------------------------------------------------------
------------------------------------------------------------------------
 -----------------------------------------------------------------------
 * Tests
 
-- evalEq.translate_left_part : faire plus de verification sur les
+** evalEq.translate_left_part : faire plus de verification sur les
 index de slice 
 
-- verifier que tous les "assert false" sont vraiment innateingnables.
+** verifier que tous les "assert false" sont vraiment innateingnables.
 
-- verifier que chacun des exemples du repertoire "should_fail" échoue
+** verifier que chacun des exemples du repertoire "should_fail" échoue
 avec un bon message d'erreur. 
 A ce propos, pourquoi 
      should_fail/semantics/activation1.lus
      should_fail/semantics/activation2.lus
 sont-ils sensés échouer ?
 
----------------------------------------------------------------------
----------------------------------------------------------------------
 ---------------------------------------------------------------------
 
-* idée rigolote me vient  : faire du byte-profiling sur les tests
+* Idées rigolotes  
+
+** faire du byte-profiling sur les tests
 de non-regression, et faire  un grep de "(* 0 *)" pour  voir s'il y a
 du code mort ou bien des tests à rajouter.
         
@@ -282,7 +272,10 @@ du code mort ou bien des tests
 -----------------------------------------------------------------------
 -----------------------------------------------------------------------
 -----------------------------------------------------------------------
-* "extern", "unsafe", and "memoryless" annotations   
+
+* Misc
+
+** "extern", "unsafe", and "memoryless" annotations   
 
 Rajouter ces 3 mots clefs dans la syntaxe.
    
@@ -291,8 +284,6 @@ L'id
 	- safe (i.e., pas d'effet de bord)
 	- memoryfull (i.e., ils utilisent de la mémoire)
 
-
-
 bon, non en fait, il n'y a pas besoin de rajouter tous ces mots clefs.
      o memoryless -> function, qui existe deja
      o extern -> y'a rien besoin de dire : on regarde juste s'il y a un
@@ -314,10 +305,7 @@ alors rajouter l'option  --infer-memoryless-annotation). Ou alors, on
 se contente d'emmettre des warning.
 
 
----------------------------------------------------------------------
----------------------------------------------------------------------
----------------------------------------------------------------------
-* [solve_ident]
+** [solve_ident]
 
 finir solveIdent.ml 
 
@@ -379,15 +367,14 @@ rien
 pas bien compliquée ni bien longue...
 
 
------------------------------------------------------------------------
------------------------------------------------------------------------
+
 -----------------------------------------------------------------------
 * Flies fuck
 
-+ utiliser des Map.t dans Unify (et peut-etre ailleurs)
-+ Encapsuler le module Global.
-+ traiter les types int, real, bool dans Predef ?
-* mettre pre, current, when, etc. dans predef ?
+** utiliser des Map.t dans Unify (et peut-etre ailleurs)
+** Encapsuler le module Global.
+** traiter les types int, real, bool dans Predef ?
+** mettre pre, current, when, etc. dans predef ?
 
-+ Faire qque chose pour les 2 verrues dans predefSemantics pas facile...
-+ Essayer de tronconner le lazyCompiler, 700 lignes, c'est trop (et c'est pas fini !)
+** Faire qque chose pour les 2 verrues dans predefSemantics pas facile...
+** Essayer de tronconner le lazyCompiler, 700 lignes, c'est trop (et c'est pas fini !)