1. 15 Jun, 2018 1 commit
  2. 07 Jun, 2018 1 commit
    • Andrei Paskevich's avatar
      WhyML: allow return types with names: f (a:int) : (x: int, ghost y: int) · 0ffeb3d4
      Andrei Paskevich authored
      These names are only visible under "ensures" but not under "returns".
      If the result is named, the special variable "result" is not used.
      In a tuple, either each component should be named, or none at all.
      Underscores are allowed. Parentheses around the return type are required.
      Each name must be given its own type: "f () : (x y: int)" is rejected.
      Identifiers without cast are treated as types, not as names.
      To name the result without giving its type, use "returns".
      0ffeb3d4
  3. 12 Jan, 2018 1 commit
  4. 11 Jun, 2017 1 commit
    • Andrei Paskevich's avatar
      WhyML: tuple terms/expressions do not require parentheses · a1e032f6
      Andrei Paskevich authored
      This makes the syntax cleaner and brings us closer to OCaml.
      
      One incompatibility with the previous grammar is that "ghost"
      binds stronger than the left arrow of assignment, and thus
      ghost assignments have to be written as "ghost (x.f <- v)".
      
      This is unavoidable, because assignment has to be weaker than
      the tuple comma (think "x.f, y.g <- y.g, x.f" or "a[i] <- u,v"),
      and "ghost" has to be stronger than comma, for consistency with
      our patterns and our return types.
      
      The "return" construction is weaker than comma, for "return a,b".
      It is also weaker than assignment, though "return x.f <- b" does
      not make much sense either way.
      
      This change does not concern type expressions, where a tuple
      type must always have its clothes^Wparentheses on: (int, int).
      It might be nice to write "constant pair: int, bool", but on
      the other hand this would break casts like "42: int, true".
      a1e032f6
  5. 04 May, 2015 1 commit