1. 10 Nov, 2013 2 commits
  2. 09 Nov, 2013 2 commits
  3. 27 Oct, 2013 4 commits
    • 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.
      f26c42c4
    • Andrei Paskevich's avatar
      Typing: only accept opaqueness annotations in prototypes · 1c2e307c
      Andrei Paskevich authored
      TODO: impose the same restriction in programs
      1c2e307c
    • Andrei Paskevich's avatar
      accept untyped variables under quantifiers · 02fcd207
      Andrei Paskevich authored
      It is a matter of ongoing discussion how much type information we
      require from the user for the sake of readability of specification.
      Since types of quantified variables are important part of axioms
      and lemmas, we required them for the same reason we require the
      full prototypes for functions and predicates. However, when we
      typecheck program annotations, explicit types in quantifiers may
      quickly become an annoyance. Let's say, we define a polymorphic
      function "fn":
      
        let fn x y
          requires { forall z:'a. ... -> z = x }
        = ...
      
      Since in programs we [are going to] accept implicit type variables,
      the user may omit the types of "x" and "y", and they will be inferred
      by the typechecker. Now, if we are obliged to write the type of "z"
      in the postcondition, we cannot simply write 'a, because it will not
      unify with the implicit type of "x" (remember that programs are typed
      independently of specs). So, if we write the type of "z", we also have
      to write the type of "x". This is annoying and may even lead to errors
      if, by mistake, the user chooses 'a for the type of "x" and thus
      freezes 'a in all function definitions in "fn" while they were
      polymorphic in 'a till then.
      
      For this reason, it seems reasonable to accept untyped variables
      under quantifiers (DISCUSS: should we accept them only in specs?).
      However, we still require type variables in logic to be explicitly
      named (unless they come from the program, then they are accepted),
      and thus polymorphic axioms and lemmas would still have to have
      the explicitly typed quantified variables.
      02fcd207
    • Andrei Paskevich's avatar
  4. 26 Oct, 2013 3 commits
    • Andrei Paskevich's avatar
      Dexpr: stage 2, in progress · 2bd3fdc4
      Andrei Paskevich authored
      2bd3fdc4
    • 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.
      43aeab83
    • Andrei Paskevich's avatar
      Dexpr.dpattern and Dexpr.dexpr · c6e73ee5
      Andrei Paskevich authored
      c6e73ee5
  5. 25 Oct, 2013 1 commit
  6. 24 Oct, 2013 2 commits
  7. 23 Oct, 2013 1 commit
  8. 22 Oct, 2013 1 commit
  9. 19 Oct, 2013 2 commits
  10. 05 Oct, 2013 4 commits
  11. 04 Oct, 2013 7 commits
  12. 01 Oct, 2013 2 commits
  13. 29 Sep, 2013 1 commit
  14. 28 Sep, 2013 1 commit
  15. 25 Sep, 2013 7 commits