1. 04 Oct, 2018 1 commit
  2. 28 Sep, 2018 2 commits
  3. 24 Jun, 2018 1 commit
  4. 15 Jun, 2018 2 commits
  5. 15 Mar, 2018 1 commit
  6. 09 Mar, 2018 1 commit
  7. 06 Mar, 2018 4 commits
  8. 26 Feb, 2018 1 commit
  9. 22 Jan, 2018 1 commit
  10. 17 Jan, 2018 1 commit
  11. 01 Jun, 2017 1 commit
  12. 03 Apr, 2017 1 commit
  13. 20 Feb, 2017 1 commit
    • Leon Gondelman's avatar
      Coercions · 87b4ad35
      Leon Gondelman authored
      1. The equality symbol is now bidirectionally compatible with coercions.
      That is, in the  module Binary below (see bench/typing/good/coercions.mlw),
      goal G is well-typed, with coercion [to_int] being applied to variable [x]
      both in [x=y] and in [y=x] :
      
      module Binary
      
        use import int.Int
        use import mach.int.Int63
      
        goal G: forall x: int63, y: int. x = y /\ y = x
      
      end
      
      2. Each coercion is still uniquely defined by type symbols [Ts, Ts']
      
         [ ls: Ts1 ty_1,1 ... ty_1,n -> Ts2 ty_2,1 ... ty_2,m ],
      
      but searching for a possible coercion is now taking into account
      types [ ty_1,1 ... ty_1,n ] and [ ty_2,1 ... ty_2,m ] in order to
      compare them with the actual type of a term [t] on which coercion may
      apply as well as the actual expected type.
      
      (That is, now the signature of find is [t -> ty -> ty -> lsymbol list])
      
      This is done to anticipate in a heurstic way a situation when
      a coercion can be technically applied but will eventually fail, because
      type mismatch between types in coercion signature and the types of
      a term on which coercion applies. For instance, given a coercion
      
        function to_list bool : list bool
        meta coercion function to_list
      
      the following goal is rejected by typing:
      
        goal G: forall x: list int, y: bool.  x = y
      
      Indeed, [y] is expected to be of type [list int].
      Since [y] is of type [bool], one may try to apply a coercion [to_list]
      in order to get a term [to_list y] of type [list bool].
      However, this would not help, since a [list bool] mismatch with [list int].
      
      The error message is now better:
      
      "This term (i.e. [y]) has type bool, but is expected to have type list int"
      
      compared to old version:
      
      "This term  (i.e. [y])  has type list bool, but is expected to have type list int"
      87b4ad35
  14. 13 Feb, 2017 1 commit
  15. 11 Feb, 2017 1 commit
  16. 09 Feb, 2017 1 commit
    • Jean-Christophe Filliatre's avatar
      coercions · db0d6501
      Jean-Christophe Filliatre authored
      a slightly different representation of coercions
      (using trees instead of lists)
      bench files for coercions
      db0d6501
  17. 22 Feb, 2016 1 commit
  18. 11 Dec, 2015 1 commit
  19. 12 Oct, 2012 1 commit
  20. 04 Sep, 2012 1 commit
  21. 03 Sep, 2012 1 commit
  22. 29 Jun, 2011 1 commit
    • Andrei Paskevich's avatar
      several changes in syntax · aa2c430e
      Andrei Paskevich authored
      - No more "and", "or", "implies", "iff", and "~".
        Use "/\", "\/", "->", "<->", and "not" instead.
      
      - No more "logic". Use "function" or "predicate".
      aa2c430e
  23. 03 Jun, 2011 1 commit
  24. 03 Mar, 2011 1 commit
  25. 25 Feb, 2011 1 commit
  26. 29 Oct, 2010 1 commit
  27. 26 Oct, 2010 1 commit
    • Andrei Paskevich's avatar
      verify termination (à la Fixpoint) of recursive logic definitions · f92739a1
      Andrei Paskevich authored
      the verification algorithm must always terminate and be reasonably
      performant in practice, but its worst-case complexity is unknown
      and probably exponential. What is quite easy when there is only
      one recursive definition, becomes difficult when there is a group
      of mutually recursive definitions. An educated discussion would
      be highly appreciated.
      
      BTW, I had to convert a couple of recursive "logic"s on integers
      into an abstract "logic" + axiom. Pretty much all of them supposed
      that the argument was non-negative, and thus were non-terminating!
      f92739a1
  28. 25 Aug, 2010 1 commit
  29. 17 Jul, 2010 1 commit
  30. 24 Jun, 2010 1 commit
    • Andrei Paskevich's avatar
      - Convert the syntax of prototype declarations and type expressions · ddfa942e
      Andrei Paskevich authored
        in the logic language into (more or less) higher-order style.
        For example,
      
          logic func (x : int, y : int, 'a list) : (int, 'a) map list
      
          logic pred (bool, int * real)
      
        is now written:
          
          logic func (x y : int) (list 'a) : list (map int 'a)
      
          logic pred bool (int, real)
      
        Note that types use prefix notation (as in Coq) and the types
        of tuples are now written as (type1, type2, ..., typeN).
      
      - Use the same syntax of type expressions in the program language.
      
      - Allow binders of the form (x y:int) in the program language.
        
      ddfa942e
  31. 21 Jun, 2010 2 commits
  32. 24 Mar, 2010 1 commit
    • Andrei Paskevich's avatar
      several modifications around namespaces: · b8a9808d
      Andrei Paskevich authored
      - do not add to the new namespace the old instantiated names
      - namespaces with the same name are merged instead of raising
        an exception.
      
      Attention: examples clash_namespace1.why, already_theory1.why,
      already_theory2.why, clash_type6.why, clash_type7.why migrated 
      from bench/typing/bad/ to bench/typing/good/. Please, consult
      these files and make sure you comprehend and approve the new
      semantics.
      b8a9808d
  33. 04 Mar, 2010 2 commits