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.

* 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 ??? 
  bien que
      Not = not;
  ne fonctionne pas (bien que ca doit pouvoir)
 
 D'autant que je peux fournir le fichier src/lustre.lus aux gens... 
 si vraiment ils veulent une version prefixe de ces operateurs...

 En  effet, ca reduit  l'espace de  nommage (j'avais  d'ailleurs dans
 mes tests  de non-reg une  variable qui s'appelait "plus",  que j'ai
 du renommer  en "Plus"...). Il  faudrait d'ailleurs, si je  garde ce
 module Lustre  prédefini, que je verifie  que l'utilisateur n'essaie
 pas d'en créer un avec ce nom...
 

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

* test/should_fail/semantics/bad_call03.lus
 Moi j'accepte ca...

* autoriser les noeuds (ou fonction) sans corps sans avoir a préciser
"extern" ?

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


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


* Faire qque chose pour les 2 verrues dans predefSemantics
  pas facile...

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

* traiter les types int, real, bool dans Predef ?


* un noeud  sans memoire  pourra etre déclaré  comme "node"  ou comme
"function" que si l'option -v4-compat est donnée ?

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

*** facile

* ../lus2lic should_work/NONREG/Int.lus 

  "zero" versus "Int::zero". Ce probleme est une consequence d'un 
  mauvaix  choid  de  représentation   pour  les  ident  dans  l'abre
  syntaxique. cf le laius a propos de solveIdent.ml plus bas.

* dans evalType, je ne checke pas tous les arguments !
ecrire les tests idoines puis faire ces checks.

* verifier que chacun des exemples du repertoire "should_fail" échoue
avec un bon message d'erreur.

* mettre les operateurs temporels dans Predef ???

* Verifier que les fonctions sont des fonctions etc. 

* verifier  qu'il n'est  pas nécessaire  de verifier  que le  gens ne
  nomme pas leur package Lustre...

* splitter presefSemantics en predefType, predefClock, et predefEval

* 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


---------------------------------------------------------------------
* finir solveIdent.ml 

ca devrait corriger  le pb dans test/should_work/NONREG/alarme.lus ou
la constant "delai_reprise"  est defini comme "alarme__delai_reprise"
et utilisée comme "delai_reprise".


Paramatrize the AS  (cf SyntaxTreeCore) by the kind  of ident that is
used.  Indeed, during parsing,  we cannot always know what Ident.long
should we have, given an Ident.idref,  or a Ident.t. The idea is then
to write a function resolve_name which profile is

(Ident.idref) SyntaxTreeCore.t -> (long) SyntaxTreeCore.t

en fait,  je ne  devrais pas avoir  une distinction entre  Ident.t et
Ident.long.  Au parsing, je ne devrais generer que des idref, puis je
devrais les transformer en Ident.t  (apres merge entre les ident.t et
ident.long)

Meme les variables locales, je pourrais leur coller le nom du package
ou  leur  noeud  sont  définis (juste  histoire  d'etre  homogene)...
Mouais.  Disons que le nom du package pourrait être optionnel dans le
type Ident.t, pour qu'on ne soit  pas obligé de coller le nom du pack
aux vars locales. a voir.  L'interet  de ma manip, c'est que une fois
que la gestion des idents  est cantonnée à un module travaillant sur
un type abstrait, je peux changer ca à ma guise apres.

par ailleurs, ce nouveau Ident.t contiendrait également la
facon dont il était reférencé dans le programme source
(pour le pretty-print).  Il pourrait etre defini ainsi :

 	type t = pack_name * string * string


nb :  il reste  meme des idref  dans compiledData  ! Je ne  sais plus
precisement  pour  quelle raison  d'ailleurs.  Je  me souviens  avoir
essayer des mettre  des ident à la place, et j'ai  du renoncer car je
ne m'en sortais pas.

qu : à quoi ressemblera resolve_name ?

 -> a un gros parcours recursif sur SyntaxTreeCore.t ! 


o inconvénients
 - va y avoir beaucoup de loc qui ne feront rien dans cette fonction...
 - pas mal d'effort pour obtenir grosso-merdo le même code rangé autrement

o  avantages
 - ce sera mieux rangé ! (tout ce qui traite de ca dans un module à lui)
 - cette histoire de résolution de noms est éparpillée dans plein de 
   modules, qu'elle pollue et fait grossir (cf lazycompiler)
 - merger ident.t et long, je suis sur que ca va simplifier plein de choses
 - 

par exemple, les fonctions LazyCompiler.solve_x_idref n'auraient plus
rien à faire dans ce module  ! Le truc c'est que cette fonction n'est
pas bien compliquée ni bien longue...
-----------------------------------------------------------------------


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



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.