1. 05 Jun, 2017 1 commit
    • Andrei Paskevich's avatar
      Mlw: local exceptions in the surface language · b3a73a61
      Andrei Paskevich authored
      current syntax is
      
          exception Return (int, ghost bool) in
          ...
          try
            ...
            raise Return (5, false)
            ...
          with
            Return (i, b) -> ...
          ...
      
      These exceptions can carry mutable and non-monomorphic values.
      They can be raised from local functions defined in the scope
      of the exception declaration.
      b3a73a61
  2. 03 Jun, 2017 1 commit
  3. 27 May, 2017 1 commit
    • Andrei Paskevich's avatar
      Mlw: support Epure in the surface language (with type inference) · 72714897
      Andrei Paskevich authored
      The current syntax is "{| <term> |}", which is shorter than
      "pure { <term> }", and does not require a keyword. Better
      alternatives are welcome.
      
      As for type inference, we infer the type pf the term under Epure
      without binding destructible type variables in the program.
      In particular,
        let ghost fn x = {| x + 1 |}
      will not typecheck. Indeed, even if we detect that the result
      is [int], the type of the formal parameter [x[ is not inferred
      in the process, and thus stays at ['xi].
      
      Another problem is related to the fact that variable and function
      namespaces are not yet separated when we perform type inference.
      Thus both fuctions
        let ghost fn (x: int) = let x a = a in {| x + 5 |}
      and
        let ghost fn (x: int) = let x a = a in {| x 5 |}
      will not typecheck, since the type of [x] is ['a -> 'a] when
      we infer the type for the Epure term, but it becomes [int],
      when we construct the final program expression. Probably,
      the only reasonable solution is to keep variables and
      functions in the same namespace, so that [x] simply can
      not be used in annotations after being redefined as a
      program function.
      72714897
  4. 28 Apr, 2017 1 commit
  5. 12 Apr, 2017 1 commit
  6. 15 Feb, 2017 1 commit
  7. 23 Aug, 2016 1 commit
  8. 28 Jul, 2016 1 commit
  9. 26 Jul, 2016 1 commit
  10. 15 Mar, 2016 3 commits
  11. 10 Jan, 2016 1 commit
    • Andrei Paskevich's avatar
      Mlw: allow non-ghost expressions to return (partially) ghost values · 4c79348a
      Andrei Paskevich authored
      this is still work in progress and no testing was done so far.
      
      Highlights of this commit:
      
      - "(ghost 42, 15)" is now a non-ghost expression that can be returned
        from a function and/or matched against a "(ghost x, y)" pattern.
        Only the tuple constructor and direct pattern matching are magical:
        "let z = (ghost 42, 15) in ..." still makes z ghost, and therefore
        "snd (ghost 42, 15)" is ghost, too.
      
      - "if c then e1 else ghost e2" and "let z = e1 in ghost e2" are now
        non-ghost expressions with a ghost result. This means that e1 may
        have visible effects. Of course, if e2 raises exceptions, the whole
        expression is ghostified. Contamination is still done when possible,
        that is, when the contaminated expression has no visible effects.
      
      - "let ghost x = e1 in e2" no longer ghostifies e1.
      
      - "let f (ghost x) = ... in f e1" no longer ghostifies e1.
      
      - new syntax: variables in program patterns may be marked ghost.
        In particular: "let x, ghost y = ...".
      
      - new syntax: the function result type may be written as a partially
        ghost tuple: "val f ... : ghost int" or "any (int, ghost bool)".
        The ghostness annotation is required for top-level and recursive
        functions.
      
      - exceptions can carry partially ghost tuples (API only, WIP)
      4c79348a
  12. 18 Sep, 2015 1 commit
  13. 15 Jul, 2015 1 commit
    • Andrei Paskevich's avatar
      Parser: relation chaining is guided by the operator group · c67b99bd
      Andrei Paskevich authored
      All infix operations in the weakest priority group (those containing
      at least one of the characters '=', '<', '>', or '~') are considered
      non-associative and the chains (t1 OP t2 OP t3) are translated into
      conjunctions (t1 OP t2 /\ t2 OP t3).
      
      This does not concern implication '->' and equivalence '<->'
      which are right-associative. like the rest of propositional
      connectives.
      c67b99bd
  14. 02 Jul, 2015 1 commit
  15. 27 Jun, 2015 1 commit
  16. 09 Jun, 2015 1 commit
  17. 29 Apr, 2015 1 commit
  18. 20 Mar, 2015 2 commits
  19. 19 Mar, 2015 1 commit
  20. 18 Feb, 2015 1 commit
  21. 21 Jan, 2015 2 commits
  22. 20 Jan, 2015 1 commit
  23. 19 Jan, 2015 1 commit
    • Andrei Paskevich's avatar
      Expr: rename 'psymbol' to 'rsymbol' (routine) · 58586dac
      Andrei Paskevich authored
      1. We really need to distinguish first-class functions (mappings),
      pure logical functions (functions and predicates), and program
      functions (routines).
      
      2. The ps_ prefix is already used for predicate symbols.
      
      3. 'psymbol' and 'pvsymbol' are too similar.
      58586dac
  24. 21 Dec, 2014 1 commit
  25. 19 Dec, 2014 2 commits
  26. 22 Oct, 2014 1 commit
  27. 14 Mar, 2014 1 commit
  28. 20 Jan, 2014 1 commit
    • Andrei Paskevich's avatar
      WhyML: add "diverges", "reads {}", and "writes {}" effect clauses · 83858597
      Andrei Paskevich authored
      - "diverges" states that the computation may not terminate (which
        does not mean that is always diverges: just as any other effect
        annotation, this clause states a possibility of a side effect).
      
      - "reads {}" states that the computation does not access any variable
        except those that are listed elsewhere in the specification (or the
        proper function arguments, if "reads" is in a function spec).
      
      - "writes {}" states that the computation does not modify any mutable
        value.
      
      - If a function definition or an abstract computation may diverge,
        but there is no "diverges" clause in the specification, a warning
        is produced. If a function definition or an abstract computation
        always terminates, but there is a "diverges" clause in the spec,
        an error is produced.
      
      - If there is a "reads" or a "writes" clause in a function definition
        or an abstract computation, then every modified value must be listed
        in "writes" and every accessed external variable not mentioned in
        the spec must be listed in "reads". (Notice that this is a stricter
        requirement than before, when the presence of a "writes" clause
        did not require to specify "reads".) However, one does not have to
        write "reads {}" or "writes {}" if the corresponding lists are empty.
      83858597
  29. 25 Nov, 2013 1 commit
    • Andrei Paskevich's avatar
      WhyML: generalize in let-in (value restriction) · 07d793f0
      Andrei Paskevich authored
      Up to now, WhyML managed without generalization in let-in,
      since we only generalized function definitions in Erec.
      This patch adds generalization of arrow-types values,
      such as effectless Eany (= abstract local functions),
      anonymous functions and psymbols.
      07d793f0
  30. 24 Nov, 2013 1 commit
  31. 19 Nov, 2013 5 commits