1. 22 Feb, 2013 2 commits
  2. 21 Feb, 2013 1 commit
  3. 19 Feb, 2013 2 commits
  4. 18 Feb, 2013 3 commits
  5. 17 Feb, 2013 12 commits
  6. 15 Feb, 2013 4 commits
  7. 14 Feb, 2013 1 commit
  8. 13 Feb, 2013 6 commits
  9. 12 Feb, 2013 7 commits
  10. 11 Feb, 2013 1 commit
  11. 09 Feb, 2013 1 commit
    • Andrei Paskevich's avatar
      whyml: accept infix relation chains · 919d60bf
      Andrei Paskevich authored
      In a chain "e1 op1 e2 op2 e3 op3 e4", each relation symbol is either:
      
      - an infix symbol "=" or "<>", or
      
      - a binary symbol whose value type is Bool.bool or Prop (for lsymbols)
        and whose arguments' types are not Bool.bool.
      
      In other words, we interpret a chain as a conjunction only if there
      is no possibility(*) to interpret it as a superposition. The exception
      is only made for "=" and "<>", which are _always_ considered as
      chainable, even if they are redefined with some bogus type signatures.
      Notice that redefining "<>" has no effect whatsoever, since "<>" is
      always treated as negated "=".
      
      As for the evaluation order, the chain above would be equivalent to:
          let x2 = e2 in
          (e1 op1 x2) &&
              let x3 = e3 in
              (x2 op2 x3) &&
                  (x3 op3 e4)
      This is due to the fact that lazy conjunctions are evaluated from
      left to right, function arguments are evaluated from right to left,
      and no expression should be evaluated twice.
      
      [*] well, not really, since we consider symbols ('a -> 'b -> bool)
      as chainable, even though such chains could be interpreted as
      superpositions(**). We could treat such symbols as unchainable,
      but that would make equality and disequality doubly special cases,
      and I don't like it. We'll see if the current conditions are not
      enough.
      
      [**] what also bothers me is dynamic types of locally defined
      infix symbols, which can be type variables or Bool.bool depending
      on the order of operations in Mlw_typing. Currently, I can't come
      up with any example of bad behaviour -- we are somewhat saved by
      not being able to write "let (==) = ... in ...").
      919d60bf