-
Erwan Jahier authoredErwan Jahier authored
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…