TODO

*** questions


* 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
 - _4Pack__toto -> encore moins beau, pas idempotent


* instanciation de package <<locaux>> à d'autre package interdite
pour l'instant, alors que ca marchait chez Youssef.

* should_work/packEnvTest/packages2.lus : il y a des package +
le package principal est implicite. Autorise-t'on ce genre de mélange ?

* should_work/NONREG/simple.lus
	declaration de structure en ligne ???


* should_work/demo/alias.lus
	Quid du module Lustre ???

* enum : avec des parentheses ou des accolades ?

* autorise t'on les trucs du genre:
   
        min_4 = min_n<< 4, toto<<2>> >> ;

   ou doit-on ecrire

      toto_2 = toto<<2>>;
      min_4 = min_n<< 4, toto_2 >> ;

?

* mettre pre, current, when, etc. dans predef ?

* dans le cas des constantes statiquement evaluables j'ai defini
">" et consort comme étant polymorphes, parce que c'est
facile en caml. Mais est-ce une bonne idée ?

* le mot cled "struct" est optionel devant une definition de
structure -> est-ce vraiment une bonne idée ?

* 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...

* 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)
cad 
 	S[i] = A[first + i*step] pour i = 0 .. (size-1)

* verifier que chacun des exemples du repertoire "should_fail" à une
correspondance dans le manuel, et reciproquement...

* Que fait-on des constantes réelles ?

par exemple, dans test/should_work/NONREG/simple.lus, 

	const right = pi/2.;

est evalué (+ warning) alors qu'on ne devrait pas je trouve.

 -> à discuter

par exemple, pour les comparaisons, c'est ok à la limite. mais pour
les operateurs aritmetiques, bof.

* pour l'evaluation statique de l'egalité, j'ai pas fait pareil...
-> à discuter (cf predefInfo.ml)

o 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,
car celui ci en  a besoin et je suis obligé de  faire un match find_x
with  | Imported  -> assert  false  | Local  x_info ->  ...  pour  le
recuperer ce qui est extremement laid...
		
-> TODO : rajouter x_info en argument de x_check (et virer symbols du
coup eventuellement ?)

log:
lazycompiler.ml:
  Simplify  a  little  bit  a  couple  of  functions  (avoiding  code
  duplication basically). 

* Evaluer  statiquement  les  iterateurs  quand  c'est  possible  (cf
  evalConst.ml) ?

* rajouter  la notion  de  variables polymorphes  et sur-chargées  au
  niveau noeud utilisateur  ? Ce devrait etre peanuts  maintenant que
  je les ai en interne...

* splitter predefsemantics en predefTyping et PredefEval?
   les  function   type_error  des  predefSemantics   devraient  être
   definies ailleurs en ce cas.
   

* autoriser les  alias sur  "nor" et "#"  ? (ca complique  les choses
  pour bien peu...).

* essayer de faire qque chose pour les 2 verrues dans predefSemantics

* maintenant que je peux definir des trucs du genre
  x = map<<+;3>>
  ai-je encore besoin de Lustre::plus et consort ??? 

***********************************************************************************
***********************************************************************************
***********************************************************************************
***********************************************************************************
*** a faire

*** facile

* autoriser le  fait le  pouvoir donner une  valeur par defaut  à une
 constante exportée. («provides const : n = 4; ») 
 -> cf test/should_work/Pascal/packs.lus

* ../lus2lic -n consensus_6 should_work/Pascal/t2.lus

* Verifier que les test de map_red couvre les cas tordus.

* "1..2" ne marche pas car le lexer renvoie 
	"1." ".2" 
  au lieu de
	"1" ".." "2"
  et avec lex, il n'y a aucun moyen de lever cette ambiguité ! 

une solution crade serait de faire un coup des sed pour rajouter un
espace devant tous les "..".

une solution propre serait de ne plus utiliser lex... Une autre
solution serait de reconstruire la bonne onfo au niveau du yacc. Par
exemple, si apres un "[", on trouve un reel, on bidouille pour
generer les lexemes qui vont bien, à savoir :

	tk_real+tk_real -> tk_int+tk_dotdot+tk_int



* Dans les messages d'erreurs, le numero de colonne est faux à cause des tabulations


* Verifier que les fonctions sont des fonctions etc. 






*** moins facile

* le clock checking 

* le merge

* les itérateurs


* test/should_work/Pascal/consensus.lus

la recursion statique ne marche pas ("with (n=1)" pas pris en compte


node consensus<<const n : int>>(T: bool^n) returns (a: bool); 
let
	a = with (n = 1)
		then T[0]
		else T[0] and consensus << n-1 >> (T[1..n-1]);
tel


* evalEq.translate_left_part : faire plus de verification sur les
index de slice

* parser.mly : rajouter les pragma ! 
 ex : %ASSUME:assumeSelectElementOfRank_inArray_%
  -> 3 shift/reduce conflicts !

* patcher le mode emacs
	- rajouter modele, package, etc.
	- l'indentation est vraiment à chier

* finir de rédiger le manuel

+ verifier que j'y parle bien de la priorite des operateurs

* Essayer de tronconner le lazyCompiler, 700 lignes, c'est trop (et
c'est pas fini !)


* 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


* "extern", "unsafe", and "memoryless" annotations   

Rajouter ces 3 mots clefs dans la syntaxe.
   
L'idée, c'est que par defaut, un noeud lustre est 
	- interne (i.e., pas extern, cad défini en Lustre)
	- safe (i.e., pas d'effet de bord)
	- memoryfull (i.e., ils utilisent de la mémoire)


on pourra rajouter l'alias 
	function == extern memoryless node
pour la compatibilité ascendente

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
     corps ou pas
     o  unsafe ->  la, oui,  il faut  un mot  clef.  on  y  fera plus
     tard. Plus precisement, on verifie la cohérence de declarations 
     avec ce qui  est généré, puis on transmet  l'info telle quelle à
     lic si tout est correct. 


nb  : pour les  noeuds «internes»,  on peut  se passer  de d'indiquer
 qu'il s'agit d'une "function", qui est "unsafe" dans la mesure où on
 sait toujours  inferer ces  infos. Mais laisser  les gens  le mettre
 s'ils le veulent, ca ne mange pas de pain.

nb2  : rejeter  les noeuds  sans  memoire (ce  faisant sans  indiquer
"function", ca  ne serait pas  backward compatible. Mais  on pourrait
alors rajouter l'option  --infer-memoryless-annotation). Ou alors, on
se contente d'emmettre des warning.

nb3 : function = memoryless node