- May 27, 2008
-
-
Erwan Jahier authored
when trying to unify, e.g., "a^3" and "int^3". Such kind of things occured when one imbricates iterators. In fact, it was not possible to get it rigth with the data representation used for node profiles, which was not sufficiently general.
-
Erwan Jahier authored
work yet though (returns the wrong type). Also add the struct printer, and fix a bug in the static argument printing.
-
Erwan Jahier authored
work yet though (returns the wrong type). Also add the struct printer, and fix a bug in the static argument printing.
-
- May 26, 2008
-
-
Erwan Jahier authored
overloaded operator. Moreover, do not try to check that int or real constant are ok. It is the role of the host language.
-
Erwan Jahier authored
-
Erwan Jahier authored
performed. The resulting code is both more compact, and more general. It is more general, since that predef operators are now represented by node_exp_eff, exactly as user nodes. Hence, all the functions that were operating on user nodes via node_exp_eff (such as, node aliasing) works for free on predef op! In order to be able to perform that generalisation, it was necessary to extend sligthly the data structure used to represent the node profile in CompiledData.node_exp_eff with information indicating if a variable is polymorphic or overloaded. Not that, currently, polymorphic or overloaded variables can only be introduced by predef operators. But I think it would be easy to add those notions for normal user nodes after this change. New non-reg files boolred now compiles. Those involving - boolred - alias on predef.op
-
- May 21, 2008
-
-
Erwan Jahier authored
Also, node aliased to other nodes were handled poorly: I was replacing in the syntax tree the node by its alias. Now, I really define the alias node using the aliases one. For instance, node toto(x:t) returns (y:t); let ... tel node titi = toto; node tutu(...) returns(...); let ... z = titi(a); tel was compiled into node toto(x:t) returns (y:t); let ... tel node tutu(...) returns(...); let ... z = toto(a); tel Now, I generate node toto(x:t) returns (y:t); let ... tel node titi(i1:t) returns (o1:t); let o1 =toto(i1); tel node tutu(...) returns(...); let ... z = titi(a); tel which is equivalent, but closer to the original program.
-
- May 20, 2008
-
-
Erwan Jahier authored
they were not abstract.
-
Erwan Jahier authored
-
Erwan Jahier authored
-
Erwan Jahier authored
-
Erwan Jahier authored
-
Erwan Jahier authored
(support for fill, red, etc. is coming soon). In order to add support for iterators, I have extended the by_pos_op (and the by_pos_op_eff) data type with a list of static arguments. In other words, iterators are handled as a particular case of predefined operators.
-
- May 16, 2008
-
-
Erwan Jahier authored
-
Erwan Jahier authored
command-line) to compile a node in a package that does not exist.
-
Erwan Jahier authored
functions. But Those functions are also used by the Lazycompiler.x_check_interface_do, so that items declared in the provide part were printed twice the generated code. This change removes the item printing for items compiled from the provide part.
-
Erwan Jahier authored
Also, make sure that "make test" returns a non empty exit code so that "make cia" does not perform the commit when the test fails...
-
Erwan Jahier authored
-
- May 15, 2008
-
-
Erwan Jahier authored
t, and a node returning such a t, the compiler was actually returning the type definition of t (instead of the abstract type). In order to fix that, it was necessary to add in argument of Lazycompiler.solve_x_idref a flag (named provide_flag) indicating whether the item being compiled appears in the provide, or in the body part of the package. This fix triggered another bug that we also fix: indeed, it is not correct to return a compile error when the provided parameters of a node is not equal to its implementation. Indeed, such parameters can be abstract type that are defined in that package. The test "should_work/packEnvTest/packages.lus" is now ok.
-
- May 07, 2008
-
-
Erwan Jahier authored
type 'a hereflagged = Here of 'a | NotHere of Ident.long into type 'a elt = Local of 'a | Imported of Ident.long * static_arg list i.e., i am basically doing two things: - fix poor naming - adding static arg to nodes indeed, when compiling an equation that involves nodes defined in another package, I need to check that the static args and the static params match. Therefore I need to have the static params ! Therefore I add them (I will use them in the next commit). Moreover, in SyntaxTreeCore.node_info, the static_params list was an option type, which is a bit weird (empty lists are enough to represent node with no static params).
-
- May 02, 2008
-
-
Erwan Jahier authored
not compile them is (well, was) the default...). also, during pretty-printing, remove the type in the constant definition (e.g., "const x = 42;" instead of "const x = 42:int;"), except if it is an abstract constant of course
-
- Apr 02, 2008
-
-
Erwan Jahier authored
tests. Also, Add the possibility to have several lustre files in the command-line arguments. remove the power operator. Define a lustre.lus that contains a packaged version of Lustre predefined operators. It will be in the standard lustre library, and should be accessible directly (path).
-
Erwan Jahier authored
in the shoud_work directory!).
-
Erwan Jahier authored
For non-regression tests, do not use Lazycompiler.test function anymore and just use LazyCompiler.node_check instead. put in the new file compiledDataDump.ml all the stuff related to string convertions of CompiledData items.
-
- Mar 28, 2008
-
-
Erwan Jahier authored
and anonymous structures. I've even found some type errors in the non-reg files!
-
- Mar 20, 2008
-
-
Erwan Jahier authored
operators. Predef contains the abstract syntax of those operators (taken for SyntaxTreeCore.by_pos_op), and PredefSemantics contains: - const_eval: that says how to statically evaluate constants - type_eval: that provides the type profile of predef operators - clock_eval: that provides the clock profile of predef operators The code in EvalConst that dealt with predef const evaluation is now in Predef.const_eval
-
- Mar 17, 2008
-
-
Erwan Jahier authored
EvalNode.f -> GetEff.node, EvalType.f -> GetEff.typ, EvalEq.f -> GetEff.eq EvalConst.f (val_exp -> const_eff list) should have been put there too, but in fact EvalConst.f ougth to be splitted in two parts: - val_exp -> val_exp_eff (but this function already exist) - val_exp_eff -> const_eff list Therefore, the signature of EvalConst.f will be changed to: val_exp_eff -> const_eff list (and will use GetEff.val_exp) Ditto for eval_array_index. eval_array_index : CompiledData.id_solver -> SyntaxTreeCore.val_exp -> int -> int ougth to be splitted into two functions: - CompiledData.id_solver -> SyntaxTreeCore.val_exp_eff - SyntaxTreeCore.val_exp_eff -> int -> int Ditto for eval_array_size eval_array_size : CompiledData.id_solver -> SyntaxTreeCore.val_exp -> int ougth to be splitted into two functions: - CompiledData.id_solver -> SyntaxTreeCore.val_exp_eff - SyntaxTreeCore.val_exp_eff -> int arg... evalConst.f est utilis par GettEff.typ !!!
-
- Mar 14, 2008
-
-
Erwan Jahier authored
-
Erwan Jahier authored
-
Erwan Jahier authored
values could not be exported, while expandPack.ml was exporting it.
-
Erwan Jahier authored
by piping the output od find by sort in the test/Makefile.
-
Erwan Jahier authored
This is done via the new module EvalEq. A lot of new errors appear in the on-reg tests, which is normal as quite a lot of the code is now used...
-
- Mar 11, 2008
-
-
Erwan Jahier authored
predefined nodes. The idea is that the Predef module will contain all the necessary information to build a node_info_eff for each of the predefined operator. It migth makes thing more difficult to deal with overling, but we'll see later how to fix that. Anyway, not all the predefinef operator are overloaded, so...
-
Erwan Jahier authored
used in order to make it homogoneous with what is done in SyntaxTreeCore.ml This commit is related to the previous one actually. Also remove all this story of node_half_eff that is not used (yet), and that may not be useful (we'll see later). Also continue to fix the representation of SyntaxTrreCore.node_info : -> remove the node alias -> put the corresponding infomation in node_body field -> rename node_body field into node_def -> associate to node_def (instead of a body option) a new union type made of Abstract, Extern, Alias of ..., Body of ... This allows us to - remove an "assert false" to deal with node with body and alias (this new presentation makes it impossible) - Deal with Abstract node properly
-
Erwan Jahier authored
change is - make the parser simpler - make the compilation simpler - make everything simpler actually... - accepts more correct programs. - etc. Indeed, before, we had specific syntax nodes for - extern nodes - aliased nodes - abstract nodes - normal nodes which leads to duplicate code everywhere. Now, we have a more generic representation. The nice thing is that the parser is much simpler, and a lot of duplicated code is avoided (for example, extern and abstract nodes do now share the same code). The bad thing is that we have more "assert false" lying everywere due to this «too rich» representation, in order to deal with cases that can never happen. For exemple, we have to do something with nodes that have both an alias and a body. This cannot happen of course, so we issue an "assert false", which is a little bit painful, as it have been rejected by the parser anyway. Moreover, for some reason, external node params could not be clocked, and cannot have static params. Maybe it is not possible to compile such nodes (I don't know yet), but we should not raise a syntax error IMHO. Somehow, what was done was very similar to ask the parser to perform type checking.
-
- Mar 06, 2008
-
-
Erwan Jahier authored
EvalNode.f rename back predef_node into by_pos_op.
-
Erwan Jahier authored
i.e., a = operator +(1,3); or a = map<<operator +>>(l); This is to simplify the syntax tree. We migth undo this change in the future, or perform the same thing differently.
-
Erwan Jahier authored
sensible to flushing, which is painful.
-
Erwan Jahier authored
-
Erwan Jahier authored
-