diff --git a/src/TODO b/src/TODO.org
similarity index 67%
rename from src/TODO
rename to src/TODO.org
index 5235040f65b86721bd0e4620ff07a3eddf01608a..feabb2ba6a395f3257f96d077d61d474a8730403 100644
--- a/src/TODO
+++ b/src/TODO.org
@@ -1,20 +1,19 @@
-*********************************************************************
-*********************************************************************
-*** 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 !)