| Commit message (Collapse) | Author | Age |
|---|
| | |
|
| |
|
|
|
|
|
|
|
| |
This allows to factorize code and prevents the unnecessary use of back and
forth conversions between the various types of terms.
Note that functions from typing may now raise errors as PretypeError rather
than TypeError, because they call the proper wrapper. I think that they were
wrongly calling the kernel because of an overlook of open modules.
|
| | |
|
| |
|
|
|
|
|
| |
Strangely enough, the checker seems to rely on an outdated decompose_app
function which is not the same as the kernel, as the latter is sensitive
to casts. Cast-manipulating functions from the kernel are only used on
upper layers, and thus was moved there.
|
| |\ |
|
| | |\ |
|
| | | | |
|
| | | | |
|
| | | | |
|
| |\| | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The bytecode interpreter ensures that the stack space available at some
points is above a static threshold. However, arbitrary large stack space
can be needed between two check points, leading to segmentation faults
in some cases.
We track the use of stack space at compilation time and add
an instruction to ensure greater stack capacity when required. This is
inspired from OCaml's PR#339 and PR#7168.
Patch written with Benjamin Grégoire.
|
| | | | |
|
| |\| | |
|
| | | | |
|
| |\| | |
|
| | |\| |
|
| | | |
| | |
| | |
| | |
| | | |
side_effects. Partial solution to the handling of side effects
in proofview.
|
| | | | |
|
| |\| | |
|
| | |\ \
| | | |
| | | |
| | | | |
Was PR#263: Fast lookup in named contexts
|
| | | | |
| | | |
| | | |
| | | | |
replaced with the recommended "Filename.get_temp_dir_name".
|
| |\| | | |
|
| | |\ \ \
| | | |/
| | |/| |
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The greatest danger of OCaml's polymorphic equality is that PMP can
replace it with pointer equality at any time, be warned :)
The lack of optimization may account for an exponential blow-up in size
of the generated code, as well as worse runtime performance.
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
This field was only used by the VM before, but since the previous patches,
this part of the code relies on the map instead.
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | |/
| |/| |
|
| |\ \ \ |
|
| |\ \ \ \
| | |/ /
| |/| | |
|
| | | | | |
|
| |\| | | |
|
| | | | |
| | | |
| | | |
| | | | |
Spotted by PMP.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
composition operator.
Short story:
This pull-request:
(1) removes the definition of the "right-to-left" function composition operator
(2) adds the definition of the "left-to-right" function composition operator
(3) rewrites the code relying on "right-to-left" function composition to rely on "left-to-right" function composition operator instead.
Long story:
In mathematics, function composition is traditionally denoted with ∘ operator.
Ocaml standard library does not provide analogous operator under any name.
Batteries Included provides provides two alternatives:
_ % _
and
_ %> _
The first operator one corresponds to the classical ∘ operator routinely used in mathematics.
I.e.:
(f4 % f3 % f2 % f1) x ≜ (f4 ∘ f3 ∘ f2 ∘ f1) x
We can call it "right-to-left" composition because:
- the function we write as first (f4) will be called as last
- and the function write as last (f1) will be called as first.
The meaning of the second operator is this:
(f1 %> f2 %> f3 %> f4) x ≜ (f4 ∘ f3 ∘ f2 ∘ f1) x
We can call it "left-to-right" composition because:
- the function we write as first (f1) will be called first
- and the function we write as last (f4) will be called last
That is, the functions are written in the same order in which we write and read them.
I think that it makes sense to prefer the "left-to-right" variant because
it enables us to write functions in the same order in which they will be actually called
and it thus better fits our culture
(we read/write from left to right).
|
| | | | |
| | | |
| | | |
| | | | |
which can be useful in general, and then simplifying "Printer.pr_named_decl" function
|
| | | | |
| | | |
| | | |
| | | | |
"Context.Named.{to,of}_rel_decl"
|
| | | | | |
|
| |\| | | |
|
| | | | | |
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | | |
"Context.{Rel,Named}.fold_constr"
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
mainly concerning referring to "Context.{Rel,Named}.get_{id,value,type}" functions.
If multiple modules define a function with a same name, e.g.:
Context.{Rel,Named}.get_type
those calls were prefixed with a corresponding prefix
to make sure that it is obvious which function is being called.
|
| | | | |
| | | |
| | | |
| | | | |
more cleanups
|
| |\ \ \ \ |
|
| | | | | | |
|
| | | | | |
| | | | |
| | | | |
| | | | | |
This fixes #3450 and probably provides a huge speed-up to many instances.
|
| | | | | |
| | | | |
| | | | |
| | | | | |
Suggested by @ppedrot
|
| | |_|/ /
|/| | |
| | | |
| | | |
| | | |
| | | |
| | | | |
As noted by @ppedrot, the first is redundant. The patch is basically a renaming.
We didn't make the component optional yet, but this could happen in a
future patch.
|
Pierre-Marie Pédrot
Matej Kosik
Maxime Dénès
Matthieu Sozeau
Guillaume Melquiond
Matej Kosik
Emilio Jesus Gallego Arias