TODO

*** questions externes

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

* enum : avec des parentheses ou des accolades ?

* j'ai  defini  ">"  et  consort  comme  étant  polymorphes  (et  pas
seulement  surchargées),   parce  que  c'est  facile   en  caml  (via
Pervasive.comare). Mais est-ce une bonne idée ?

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

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

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

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

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

* au sujet des pragma:
 ex : %ASSUME:assumeSelectElementOfRank_inArray_%
 je les ai rajouté (un peu) dans le parseurs
  -> 3 shift/reduce conflicts !
  et puis  il faut  que je  les mettre partout  -> changer  une autre
 regle ? sxIdent ?

***********************************************************************************
***********************************************************************************
*** questions pour bibi

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

* splitter predefsemantics en predefTyping et PredefEval?
   les  function   type_error  des  predefSemantics   devraient  être
   definies ailleurs en ce cas.
   
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). 

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

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


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

*** facile


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

* quand  je passe  2 fichiers  en arg  de la  ligne de  commande, sur
  numero de ligne du 2eme est faux (pas remis a 0).

* Verifier que les fonctions sont des fonctions etc. 



*** moins facile

* le clock checking 

* le merge

* Recursion statique

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

../lus2lic should_work/Pascal/consensus.lus
../lus2lic should_work/Pascal/t2.lus
../lus2lic should_work/Pascal/t0.lus 

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 

* 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

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


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