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

* apropos d'intanciation, j'autorise "is" et "="
  package Pint = m1( int );
mais j'ai bien envie de virer "is".

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

* Dans les messages d'erreurs, le  numero de colonne est faux � cause
  des tabulations : y'at'il quelque chose a faire ? 

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

* Verifier que les fonctions sont des fonctions etc. 

* Encapsuler le module Global.

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

* verifier que tous les "assert false" sont vraiment innateingnables.

* 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