* 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 ?
- 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
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)
** 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
pour bien peu... La difficult� �tant du � l'arit� variable de ces operateurs).
** 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:
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
"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...
** soc = synchronous object component, c'est pas mieux comme nom ?
** 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 ?
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 ? )
ex :
a=b;
b=a;
cf
test/should_fail/semantics/def.lus
test/should_fail/semantics/piege.lus
* Questions pour bibi
** 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.
** 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).
** 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)" ?
ou bien rajouter un mot clef "whenot" comme Marc?
** 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" ?
* 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" ?
** 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
de non reg ne semblent avoir echouer ?
** Ne pas g�n�rer de "current", "->", "pre" (i.e., les traduire en
termes de "merge" et "fby").
** rajouter "mirror"?
** --help devrait retourner la liste des operateurs predefinis, avec
leur type
** Verifier que les fonctions sont des fonctions etc.
** 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
un string, pas par un entier
** le merge
** 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
** 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
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
correspondance dans le manuel, et reciproquement...
** Dans la doc, distinguer 2 sortes de polymorphismes : le
polymorphisme faible, et le polymorphisme fort, qui accepte les
tuples!
les operateurs polymorphes au sens fort sont : fby, ->, current, pre, ite
+ les tuples eux-memes...
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
index de slice
** verifier que tous les "assert false" sont vraiment innateingnables.
** 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�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.
-> ecrire des tests pour exercer les fonctions suivantes (
faire "make grep" pour MAJ)
- Eff.clock_are_equals l.1 (1)
- Eff.subst_type (4)
- Eff.type_of_const (1)
- EvalClock.is_a_sub_clock (4)
- EvalClock.get_val_exp_eff (1)
- EvalClock.f_aux (1)
- EvalClock.eval_by_pos_clock (7)
- EvalConst.make_slice_const (1)
- EvalConst.make_array_const (1)
- EvalConst.make_struct_const (1)
- EvalConst.f (46)
- EvalConst.eval_array_size (3)
- EvalConst.eval_array_index (3)
- EvalConst.check_int (1)
- EvalConst.eval_array_slice (6)
- EvalType.f (2)
- EvalType.eval_by_pos_type (18)
- EvalType.eval_by_name_type (1)
- ExpandPack.doit (12)
- GetEff.typ (2)
- GetEff.type_check_equation (2)
- GetEff.check_static_arg (4)
- GetEff.translate_left_part (4)
- GetEff.translate_by_name_op (2)
- GetEff.get_const (1)
- GetEff.get_node (3)
- GetEff.translate_predef_static_args (1)
- GetEff.translate_iteror (1)
- GetEff.translate_by_pos_op (6)
- GetEff.assertion (2)
- Ident.idref_of_string (1)
- Ident.long_of_string (1)
- LazyCompiler.lookup_x_eff (1)
- LazyCompiler.lookup_type_eff (1)
- LazyCompiler.solve_x_idref (1)
- LazyCompiler.type_check_interface_do (1)
- LazyCompiler.const_check_interface_do (3)
- LazyCompiler.type_check_do (3)
- LazyCompiler.const_check_do (2)
- LazyCompiler.node_check_interface_do (6)
- LazyCompiler.node_check_do (6)
- LicDump (30)
- Lxm (4)
- Main (32)
- ParserUtils (3)
- Predef (47)
- PredefEvalConst (34)
- PredefEvalType (23)
- SolveIdent (3)
- Split (2)
- SymbolTab (20)
- SyntaxTab (12)
- SyntaxTree (7)
- UnifyClock (1)
- UnifyType (37)
- UniqueOutput (10)
-----------------------------------------------------------------------
-----------------------------------------------------------------------
-----------------------------------------------------------------------
* Misc
** "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.
** [solve_ident]
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". [corrig� autrement depuis]
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 lignes de code 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...
-----------------------------------------------------------------------
* 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 ?
** 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 !)