Skip to content
Snippets Groups Projects
  1. May 27, 2008
  2. May 26, 2008
    • Erwan Jahier's avatar
      Add error messages when one tries to alaias a polymporphic or a · de984fca
      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.
      de984fca
    • Erwan Jahier's avatar
      * mapred -> fillred · b3051f50
      Erwan Jahier authored
      b3051f50
    • Erwan Jahier's avatar
      I have complety rewritten the way predef operator typing is · b09c78c5
      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
      b09c78c5
  3. May 21, 2008
    • Erwan Jahier's avatar
      Add support to be able to use iterators in node aliases. · 65b93560
      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.
      6.13.0
      65b93560
  4. May 20, 2008
  5. May 16, 2008
  6. May 15, 2008
    • Erwan Jahier's avatar
      Fix a bug where, when defining a package exporting an abstract type · 16344043
      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.
      6.9.1
      16344043
  7. May 07, 2008
    • Erwan Jahier's avatar
      In symbolTab.ml, change · 956514c2
      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).
      6.9.0
      956514c2
  8. May 02, 2008
  9. Apr 02, 2008
  10. Mar 28, 2008
  11. Mar 20, 2008
    • Erwan Jahier's avatar
      Add two new modules, Predef and PredefSemantics, that deals with predefined · 4c0a0b1f
      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
      4c0a0b1f
  12. Mar 17, 2008
    • Erwan Jahier's avatar
      Merge EvalType, EvalNode and EvalEq into a single module GetEff. · 64fca779
      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 !!!
      64fca779
  13. Mar 14, 2008
  14. Mar 11, 2008
    • Erwan Jahier's avatar
      Remove in node_info_eff the distinction between user nodes, and · f9408138
      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...
      f9408138
    • Erwan Jahier's avatar
      Simplify the node_eff representation as well as change the names · 57431a16
      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
      57431a16
    • Erwan Jahier's avatar
      Simplify significantly the node representation. The rational for this · 7f628ceb
      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.
      6.3.0
      7f628ceb
  15. Mar 06, 2008
Loading