GitLab

- requires a lot more testing
- support in extraction missing (exception raised)
- interaction with "syntax literal" remains to investigate

x.{f} is allowed and can be used for unary applications
M.{f} is not allowed, use {M.f} instead

It is confusing to use the keyword "label" to define an exception.
Also, the "label L in ..." binds too far and the break point is
not clearly defined.

We do need some syntactic sugar for
  exception X t in try <expr> with X r -> r
(at the very least "break" and "continue"), but labels are not it.

In the surface language, the loop index is always int in
the loop invariant and all annotations and pure terms inside
the loop. If you want to access the original range-typed index,
use "let copy_i = i in" in the program code before your assertion.
Of course, you cannot do that for the loop invariant, which is
what we want.

This allows to import an existing scope to the current namespace.
Not sure if we need this in the surface language, though.

In this way, someone who puts a part of his function
in an abstract block will not have broken "return"s.

Useful to break out of the loops:

  label Break in
  while ... do
    label Continue in
    ... raise Break ...
    ... raise Continue ...
  done

When a label is put over a non-unit expression,
raise acts as return:

  label Return in
  if ... then raise Return 42; 0

Also, "return <expr>" returns from the innermost function.
This includes abstract blocks, too, so if you want to return
across an abstract block, you should rather use a label at
the top of the main function. TODO/FIXME: maybe we should
let "return" pass across abstract blocks by default, to
avoid surprises?

One shortcoming of the labels-as-exceptions is that they cannot
be used to transmit tuples with ghost elements, nor return ghost
values from non-ghost expressions. A local exception with an
explicit mask should be used instead. Similarly, to return
a partially ghost value from a function, it must have have
its mask explicitly written (which is a good practice anyway).
We cannot know the mask of an expr before we construct it,
but in order to construct it, we need to create the local
exceptions first.

Another caveat is that while it is possible to catch an exception
generated by a label, you should avoid to do so. We only declare
the local exception if the expression under the label _raises_
the exception, and thus the following code will not typecheck:

  label X in (try raise X with X -> () end)

Indeed, the expression in the parentheses does not raise X,
and so we do not declare a local exception X for this label,
and so the program contains an undeclared exception symbol.

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.

Since local exceptions can carry results with type variables
and regions, we need to freeze them in the function signatures.

This is a prototype version that requires no additional annotation.
In addition to the existing rules of scoping:

  - it is forbidden to declare two symbols with the same name
    in the same scope ("everything can be unambiguously named"),

  - it is allowed to shadow an earlier declaration with a newer one,
    if they belong to different scopes (e.g., via import),

we define one new rule:

  - when an rsymbol rs_new would normally shadow an rsymbol rs_old,
    but (1) both of them are either
      - binary relations: t -> t -> bool,
      - binary operators: t -> t -> t, or
      - unary operators:  t -> t
    and (2) their argument types are not the same,
    then rs_old remains visible in the current scope.
    Both symbols should take non-ghost arguments and
    return non-ghost results, but effects are allowed.
    The name itself is not taken into account, hence
    it is possible to overload "div", "mod", or "fact".

Clause (1) allows us to perform type inference for a family of rsymbols,
using an appropriate generalized signature.

Clause (2) removes guaranteed ambiguities: we treat this case as
the user's intention to redefine the symbol for a given type.

Type inference failures are still possible: either due to
polymorphism (['a -> 'a] combines with [int -> int] and
will fail with the "ambiguous notation" error), or due
to inability to infer the precise types of arguments.
Explicit type annotations and/or use of qualified names
for disambiguation should always allow to bypass the errors.

Binary operations on Booleans are treated as relations, not as
operators. Thus, (+) on bool will not combine with (+) on int.

This overloading only concerns programs: in logic, the added rule
does not apply, and the old symbols get shadowed by the new ones.

In this setting, modules never export families of overloaded symbols:
it is impossible to "use import" a single module, and have access to
several rsymbols for (=) or (+).

The new "overloading" rule prefers to silently discard the previous
binding when it cannot be combined with the new one. This allows us
to be mostly backward compatible with existing programs (except for
the cases where type inference fails, as discussed above).

This rule should be enough to have several equalities for different
program types or overloaded arithmetic operations for bounded integers.
These rsymbols should not be defined as let-functions: in fact, it is
forbidden now to redefine equality in logic, and the bounded integers
should be all coerced into mathematical integers anyway.

I would like to be able to overload mixfix operators too, but
there is no reasonable generalized signature for them: compare
"([]) : map 'a 'b -> 'a -> 'b" with "([]) : array 'a -> int -> 'a"
with "([]) : monomap -> key -> elt". If we restrict the overloading
to symbols with specific names, we might go with "'a -> 'b -> 'c" for
type inference (and even "'a -> 'b" for some prefix operators, such
as "!" or "?"). To discuss.

As we have to implement the "HERE" and "PARENT" qualifiers anyway,
allowing this shadowing lets us accept more programs without
compromising the "everything is unambigously nameable" invariant.

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.

We cannot split ite's and matches created in this way,
and it is hard to control how much goes into them.
Try for now to only convert bool-valued ite's.

Let's see if this helps our provers to instantiate the axiom.

Instead, we put a "stop_split" over the subsequent postcondition
under the (begin > end + 1) assumption. When this assumption is
unrealizable (strict for), this allows us to discharge the whole
branch as a single goal.

We will want to use stop_split higher in the VC formulas.

Exported [close_record_invariant] function from pdecl.ml so
that it can also be used in pmodule.ml