- 10 Jun, 2017 7 commits
-
-
Andrei Paskevich authored
A symbol is now considered overloadable if it satisfies the following conditions: - it has at least one parameter - it is non-ghost and has fully visible result - all of its parameters are non-ghost and have the same type - its result is either of the same type as its parameters or it is a monomorphic immutable type. An overloadable symbol can be combined with other symbols of the same arity and overloading kind. Otherwise, the new symbol shadows the previously defined ones. This generalisation allows us to overload symbols such as "size" or "length", and also symbols of arbitraty non-zero arity. I am reluctant to generalize this any further, because then we won't have reasonable destructible signatures for type inference.
-
MARCHE Claude authored
-
MARCHE Claude authored
-
MARCHE Claude authored
-
MARCHE Claude authored
-
MARCHE Claude authored
-
MARCHE Claude authored
-
- 09 Jun, 2017 13 commits
-
-
Andrei Paskevich authored
This reverts the enforcing part of a44cccbb.
-
Andrei Paskevich authored
This reverts commit da67461f. Let us keep the {..} notation for snapshots and shadowed logical symbols, but go back to transparent access to logical symbols, at least for now.
-
MARCHE Claude authored
-
MARCHE Claude authored
-
MARCHE Claude authored
-
MARCHE Claude authored
-
MARCHE Claude authored
-
MARCHE Claude authored
-
MARCHE Claude authored
-
MARCHE Claude authored
- requires a lot more testing - support in extraction missing (exception raised) - interaction with "syntax literal" remains to investigate
-
Jean-Christophe Filliâtre authored
- test-ocaml-extraction is back (and fixed to resolve overloaded +) - exec/extract tests that have been moved to to_port are commented out
-
Mário Pereira authored
-
Andrei Paskevich authored
-
- 08 Jun, 2017 20 commits
-
-
Andrei Paskevich authored
-
Andrei Paskevich authored
-
Andrei Paskevich authored
-
Andrei Paskevich authored
x.{f} is allowed and can be used for unary applications M.{f} is not allowed, use {M.f} instead
-
Martin Clochard authored
-
Andrei Paskevich authored
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.
-
Andrei Paskevich authored
-
Andrei Paskevich authored
-
MARCHE Claude authored
-
Martin Clochard authored
-
Martin Clochard authored
-
MARCHE Claude authored
-
MARCHE Claude authored
-
MARCHE Claude authored
-
MARCHE Claude authored
-
MARCHE Claude authored
-
MARCHE Claude authored
-
Mário Pereira authored
-
Jean-Christophe Filliâtre authored
-
Jean-Christophe Filliâtre authored
-