Skip to content
Snippets Groups Projects
  1. Dec 12, 2008
    • Erwan Jahier's avatar
      Break the recursivity is the Eff.node_exp representation (which fix nested iter. pbs). · 5c722d86
      Erwan Jahier authored
      In  short, the  rationale for  this change,  is that  it is  having a
      recursive node_exp is
      - useless,
      - too complicated,
      - wrong w.r.t. nesting iterator calls
      
      In long:
      
      - It is useless because, at the  Eff level, a node cannot call itself
        via one  of its  static arg (which  was where the  recursivity came
        from).
      
      - and indeed, it  is much simpler to consider that  a static arg node
        can only be ident.long that identifies a node alias.
      
        This  means of  course, that  nested iterators  have  been unnested
        before,   inventing  alias   node  names   along  the   way...  And
        polymorphism makes thing difficult once again.
      
      - But the  *big* problem  with a recursive  node_exp is that  it make
        things very  complicated to (lic)dump nested  iterator call because
        of polymorphism!   Actually, it  even makes thing  complicated when
        the iterators were themselves not nested in the source code !
      
        Some ugly  things were done in  LicDump to unnest  those calls when
        printing node_exp.   But this uglyness  have a price:  tricky code,
        and bugs! Indeed, nested iterators calls were wong for example when
        using  the --inline-iterator  mode (but  i would  not  be surprised
        that is wrong in other cases...).
      
      Hence,  LicDump  is  simpler,  but  of course  LazyCompiler  is  more
      complicated.  But  this  is  reasonable:  a  pretty-printer  is  not
      supposed to be complicated.
      5c722d86
  2. Sep 15, 2008
  3. Aug 21, 2008
  4. Jul 23, 2008
  5. 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
  6. 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
  7. May 02, 2008
  8. Mar 14, 2008
  9. Feb 20, 2008
  10. Feb 12, 2008
  11. Feb 07, 2008
  12. Feb 06, 2008
    • Erwan Jahier's avatar
      src/syntaxTree.ml · 1a14b111
      Erwan Jahier authored
      src/syntaxTreeCore.ml (new file)
      	Split      syntaxTree.ml      into     syntaxTree.ml      and
      	syntaxTreeCore.ml. The idea is that lic2loc should be able to
      	use syntaxTreeCore.ml verbatim.
      
      src/lxm.ml
      src/lxm.mli
      	remove pack_name from  this module, so that it  can be shared
      	with  lic2loc too  (this is  mandatory  since it  is used  by
      	SyntaxTreeCore)
      
      src/compile.ml
      src/compiledData.ml
      src/evalConst.ml
      src/evalConst.mli
      src/evalType.ml
      src/evalType.mli
      src/expandPack.ml
      src/lazyCompiler.ml
      src/main.ml
      src/parser.mly
      src/symbolTab.ml
      src/symbolTab.mli
      src/syntaxTab.ml
      src/syntaxTreeDump.ml
      src/syntaxTreeDump.mli
      src/test/Makefile
      src/test/packs.lus
      src/test/test.res.exp
      	opening SyntaxTreeCore  module, and inline  the definition of
      	Lxm.pack_name.
      
      	Also,  begin  to  replace  oper  by node  or  predef_node  in
      	identifiers, in order to get a more consistant naming scheme.
      1a14b111
  13. Jan 30, 2008
  14. Dec 18, 2007
  15. Dec 17, 2007
  16. Dec 14, 2007
  17. Oct 19, 2007
Loading