1. 22 Nov, 2013 1 commit
  2. 20 Nov, 2013 2 commits
  3. 19 Nov, 2013 11 commits
  4. 11 Nov, 2013 3 commits
  5. 10 Nov, 2013 4 commits
  6. 09 Nov, 2013 2 commits
  7. 08 Nov, 2013 1 commit
  8. 01 Nov, 2013 1 commit
  9. 29 Oct, 2013 1 commit
    • Andrei Paskevich's avatar
      Term: do not store t_vars in terms · 7abeba05
      Andrei Paskevich authored
      we still keep bv_vars in the binders, so calculating the set
      of free variables only has to descend to the topmost binders.
      The difference on an example from BWare is quite striking:
      /usr/bin/time why3-replayer : with t_vars
      505.14user 15.58system 8:40.45elapsed 100%CPU (0avgtext+0avgdata 3140336maxresident)k
      /usr/bin/time why3-replayer : without t_vars
      242.96user 12.04system 4:16.31elapsed 99%CPU (0avgtext+0avgdata 2007184maxresident)k
      Not only we take 2/3 of memory, but we also gain in speed (less work
      for the GC, most probably).
      This patch should be tested on big WhyML examples,
      since src/whyml/mlw_*.ml are big users of t_vars.
      Thanks to Guillaume for the suggestion.
  10. 27 Oct, 2013 1 commit
    • Andrei Paskevich's avatar
      Dexpr: polymorphic recursion only for fully specified functions · f26c42c4
      Andrei Paskevich authored
      If we generalize on varible-by-variable basis, then the following
      letrecs are not the same:
        let rec f (x:'a) y = (x = y) and g (z:int) = f z z  // typechecks
        let rec g (z:int) = f z z and f (x:'a) y = (x = y)  // does not
      In the first case, we unify the type of y with 'a, and thus
      f is fully generalized in the definition of g. In the second
      case, we unify the non-generazled second argument of f with int,
      and the definition of f does not typecheck.
      Also: accept implicit type variables in programs.
  11. 26 Oct, 2013 3 commits
    • Andrei Paskevich's avatar
      Dexpr: stage 2, in progress · 2bd3fdc4
      Andrei Paskevich authored
    • Andrei Paskevich's avatar
      Pattern: add compile_bare which does not require known_map · 43aeab83
      Andrei Paskevich authored
      In pattern compilation, we only need to know the full list of
      constructors for a given type, whenever
      1. we want to check that a symbol used in a pattern is indeed
         a constructor;
      2. we want to check for non-exhaustive matching and return an
         example of a non-covered pattern, if any.
      Thus, we need to give Pattern.compile access to the current
      known_map whenever we check new declarations in Decl or Mlw_decl.
      However, once we have checked the patterns, we do not need the
      full constructor lists just to compile the match expressions.
      Just knowing the number of constructors (provided in ls_constr)
      is enough to detect non-exhaustive matching during compilation.
    • Andrei Paskevich's avatar
      Dexpr.dpattern and Dexpr.dexpr · c6e73ee5
      Andrei Paskevich authored
  12. 25 Oct, 2013 1 commit
  13. 24 Oct, 2013 1 commit
  14. 23 Oct, 2013 1 commit
  15. 22 Oct, 2013 1 commit
  16. 19 Oct, 2013 1 commit
    • Andrei Paskevich's avatar
      switch Typing to the new Dterm-based API · 460e93f8
      Andrei Paskevich authored
      - Make [Highord.pred 'a] an alias for [Highord.func 'a bool],
      rename [Highorg.(@!)] to [(@)], remove [Highorg.(@?)], remove
      the quantifiers [\!] and [\?] and only leave [\] which is the
      only true lambda now;
      - Allow mixing bool and Prop in logic, Dterm will introduce
      coercions where necessary (trying to minimize the number of
      if-then-else in the term context).
  17. 16 Oct, 2013 1 commit
  18. 05 Oct, 2013 1 commit
  19. 28 Sep, 2013 1 commit
  20. 24 Sep, 2013 1 commit
  21. 23 Sep, 2013 1 commit