Skip to content
Snippets Groups Projects
  1. Aug 29, 2008
  2. Aug 28, 2008
    • Erwan Jahier's avatar
      Avoid the generation of polymorphic type variables when iterating on · 8d8dcbd0
      Erwan Jahier authored
      polymorphic operators.
      
      For instance, when LicDumping expression such as
      
          map<<map<<+,4>>,5>>
      
      an  alias  node was  created  for  "map<<+,4>>"  (to unnest  iterator
      calls). Fut this node is intrically overloaded (polymorphic). In this
      change, we  look at  the type this  innr call  is used to  generate a
      specialised (mono-morphic) version of the node alias.
      
      Note that we currently still generate type variable when users write
      
           node mymap = map<<+,4>>;
      8d8dcbd0
  3. Jun 26, 2008
    • Erwan Jahier's avatar
      A new implementation of EvalClock, that is more general. · 5dd64311
      Erwan Jahier authored
      Not yet implemented (assert false): iterators, struct
      
      Add a UnifyClock module, and rename Unify into UnifyType.
      
      nb : a lot of test are now broken, because
         - the clock checking is now plugged ;-)
         - iterators, struct are not yet implemented
      5dd64311
  4. Jun 09, 2008
    • Erwan Jahier's avatar
      Use type_eff_ext everywhere I was using type_eff (and rename · 00c67618
      Erwan Jahier authored
      type_eff_ext into type_eff btw). The  rationale is to be able to type
      alias           on           polymorphic          nodes           (cf
      test/should_fail/semantics/bad_call03.lus,  that now  have  a correct
      error msg).  It also makes  to code more compact (no more translation
      from one  to the  other), and more  general (type_eff_ext  being more
      general than type_eff).  User polymorphic nodes should be easy now.
      
      move all the code in parsey.mly into parserUtil.ml (ease the debug).
      00c67618
  5. May 28, 2008
Loading