aboutsummaryrefslogtreecommitdiffhomepage
path: root/kernel/names.ml
Commit message (Collapse)AuthorAge
* [api] Misctypes removal: miscellaneous aliases.Gravatar Emilio Jesus Gallego Arias2018-06-12
|
* [api] Remove deprecated aliases from `Names`.Gravatar Emilio Jesus Gallego Arias2018-05-30
|
* [api] Reintroduce `Names.global_reference` aliasGravatar Emilio Jesus Gallego Arias2018-05-30
| | | | | | | Due to a bad interaction between PRs, the `Names.global_reference` alias was removed in 8.9, where it should disappear in 8.10. The original PR #6156 deprecated the alias in `Libnames`.
* [api] Rename `global_reference` to `GlobRef.t` to follow kernel style.Gravatar Emilio Jesus Gallego Arias2018-05-04
| | | | | | | | | | | | | In #6092, `global_reference` was moved to `kernel`. It makes sense to go further and use the current kernel style for names. This has a good effect on the dependency graph, as some core modules don't depend on library anymore. A question about providing equality for the GloRef module remains, as there are two different notions of equality for constants. In that sense, `KerPair` seems suspicious and at some point it should be looked at.
* Allow using cumulativity without forcing strict constraints.Gravatar Gaëtan Gilbert2018-03-09
| | | | | | | | | | | | | | | | | | | | | | | | Previously [fun x : Ind@{i} => x : Ind@{j}] with Ind some cumulative inductive would try to generate a constraint [i = j] and use cumulativity only if this resulted in an inconsistency. This is confusingly different from the behaviour with [Type] and means cumulativity can only be used to lift between universes related by strict inequalities. (This isn't a kernel restriction so there might be some workaround to send the kernel the right constraints, but not in a nice way.) See modified test for more details of what is now possible. Technical notes: When universe constraints were inferred by comparing the shape of terms without reduction, cumulativity was not used and so too-strict equality constraints were generated. Then in order to use cumulativity we had to make this comparison fail to fall back to full conversion. When unifiying 2 instances of a cumulative inductive type, if there are any Irrelevant universes we try to unify them if they are flexible.
* Update headers following #6543.Gravatar Théo Zimmermann2018-02-27
|
* [api] Miscellaneous consolidation + moves to engine.Gravatar Emilio Jesus Gallego Arias2017-11-21
| | | | | | We deprecate a few functions that were deprecated in the comments plus we place `Nameops` and `Univops` in engine where they do seem to belong in the large picture of code organization.
* Use type nonrec in some functor arguments.Gravatar Gaëtan Gilbert2017-10-16
|
* Bump year in headers.Gravatar Pierre-Marie Pédrot2017-07-04
|
* A few typos.Gravatar Hugo Herbelin2017-06-04
|
* Creating a module Nameops.Name extending module Names.Name.Gravatar Hugo Herbelin2017-05-31
| | | | | | | | | | | | This module collects the functions of Nameops which are about Name.t and somehow standardize or improve their name, resulting in particular from discussions in working group. Note the use of a dedicated exception rather than a failwith for Nameops.Name.out. Drawback of the approach: one needs to open Nameops, or to use long prefix Nameops.Name.
* [cleanup] Unify all calls to the error function.Gravatar Emilio Jesus Gallego Arias2017-05-27
| | | | | | | | | | | | | This is the continuation of #244, we now deprecate `CErrors.error`, the single entry point in Coq is `user_err`. The rationale is to allow for easier grepping, and to ease a future cleanup of error messages. In particular, we would like to systematically classify all error messages raised by Coq and be sure they are properly documented. We restore the two functions removed in #244 to improve compatibility, but mark them deprecated.
* Revised behavior on ill-formed identifiers.Gravatar Hugo Herbelin2017-05-20
| | | | | Namely: Replacing (currently deactivated) warning on illegal ident by an error in strict mode and nothing in soft mode.
* Remove some unused values and typesGravatar Gaetan Gilbert2017-04-27
|
* refactoring "Names.DirPath.is_empty" functionGravatar Matej Kosik2017-04-20
|
* refactoring "Names.DirPath.compare" functionGravatar Matej Kosik2017-04-20
|
* refactoring "Names.DirPath.equal" functionGravatar Matej Kosik2017-04-20
|
* Revert "refactoring: Names.DirPath.equal"Gravatar Matej Košík2017-04-10
| | | | This reverts commit 0d364f7aa5cee042f0b327966fce35778f3285e0.
* Revert "refactoring: Names.DirPath.compare"Gravatar Matej Košík2017-04-10
| | | | This reverts commit 7a51d6a94bdd6cc889cd69fa0fbb5c8a655b2b16.
* Revert "refactoring: Names.DirPath.is_empty"Gravatar Matej Košík2017-04-10
| | | | This reverts commit e180cce2384bacaa5ad5b9d6e15b55de8cc913cc.
* refactoring: Names.DirPath.is_emptyGravatar Matej Kosik2017-04-10
|
* refactoring: Names.DirPath.compareGravatar Matej Kosik2017-04-10
|
* refactoring: Names.DirPath.equalGravatar Matej Kosik2017-04-10
|
* [safe-string] Enable -safe-string !Gravatar Emilio Jesus Gallego Arias2017-03-14
| | | | | | | | | We now build Coq with `-safe-string`, which enforces functional use of the `string` datatype. Coq was pretty safe in these regard so only a few tweaks were needed. - coq_makefile: build plugins with -safe-string too. - `names.ml`: we remove `String.copy` uses, as they are not needed.
* [safe_string] library/nameopsGravatar Emilio Jesus Gallego Arias2017-03-14
| | | | | | We add a more convenient API to create identifiers from mutable strings. We cannot solve the `String.copy` deprecation problem until we enable `-safe-string`.
* Merge branch 'v8.6'Gravatar Pierre-Marie Pédrot2016-12-07
|\
| * Fix #5242 - Dubious unsilenceable warning on invalid identifierGravatar Maxime Dénès2016-12-02
| | | | | | | | We make this warning configurable and disabled by default.
* | COMMENT: Names.Cmap and Names.Cmap_envGravatar Matej Kosik2016-10-26
| |
* | CLEANUP: switching from "right-to-left" to "left-to-right" function ↵Gravatar Matej Kosik2016-08-30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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).
* | Changing the definition of the "Lib.variable.info" type to enable us to do ↵Gravatar Matej Kosik2016-08-24
|/ | | | more cleanups
* errors.ml renamed into cErrors.ml (avoid clash with an OCaml compiler-lib ↵Gravatar Pierre Letouzey2016-07-03
| | | | | | module) For the moment, there is an Error module in compilers-lib/ocamlbytecomp.cm(x)a
* Feedback cleanupGravatar Emilio Jesus Gallego Arias2016-05-31
| | | | | | | | | | | | | | | | | | | | | | | | | This patch splits pretty printing representation from IO operations. - `Pp` is kept in charge of the abstract pretty printing representation. - The `Feedback` module provides interface for doing printing IO. The patch continues work initiated for 8.5 and has the following effects: - The following functions in `Pp`: `pp`, `ppnl`, `pperr`, `pperrnl`, `pperr_flush`, `pp_flush`, `flush_all`, `msg`, `msgnl`, `msgerr`, `msgerrnl`, `message` are removed. `Feedback.msg_*` functions must be used instead. - Feedback provides different backends to handle output, currently, `stdout`, `emacs` and CoqIDE backends are provided. - Clients cannot specify flush policy anymore, thus `pp_flush` et al are gone. - `Feedback.feedback` takes an `edit_or_state_id` instead of the old mix. Lightly tested: Test-suite passes, Proof General and CoqIDE seem to work.
* Removing dead code and unused opens.Gravatar Pierre-Marie Pédrot2016-05-08
|
* Merge branch 'v8.5'Gravatar Pierre-Marie Pédrot2016-03-30
|\
| * A patch renaming equal into eq in the module dealing withGravatar Hugo Herbelin2016-03-22
| | | | | | | | | | hash-consing, so as to avoid having too many kinds of equalities with same name.
| * Adding eq/compare/hash for syntactic view atGravatar Hugo Herbelin2016-03-22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | constant/inductive/constructor kernel_name pairs rather than viewing them from only the user or canonical part. Hopefully more uniformity in Constr.hasheq (using systematically == on subterms). A semantic change: Cooking now indexing again on full pairs of kernel names rather than only on the canonical names, so as to preserve user name. Also, in pair of kernel names, ensuring the compact representation is used as soon as both names are the same.
* | ADD: Names.Name.is_{anonymous,name}Gravatar Matej Kosik2016-02-18
| | | | | | | | | | | | | | | | | | | | Two new (trivial) functions were added: Names.Name.is_anonymous : Names.Name.t -> bool Names.Name.is_name : Names.Name.t -> bool They enable us to write a more compact code. (example: commit "99633f4" in "relation-extraction" module of "coq-contribs").
* | Merge branch 'v8.5'Gravatar Pierre-Marie Pédrot2016-01-21
|\|
| * Update copyright headers.Gravatar Maxime Dénès2016-01-20
| |
* | COMMENTS: added to the "Names.inductive" and "Names.constructor" types.Gravatar Matej Kosik2016-01-11
| |
* | COMMENTS: added to the "Names" module.Gravatar Matej Kosik2015-12-18
| |
* | Better debug printers for module paths.Gravatar Maxime Dénès2015-09-20
|/ | | | | | | | Now distinguishes between bound modules (Top#X) and submodules (Top.X). Could be useful for the regular printer as well (e.g. in error messages), but I don't know what the compatibility constraints are, so leaving it as it is for now.
* Reverting 16 last commits, committed mistakenly using the wrong push command.Gravatar Hugo Herbelin2015-08-02
| | | | | | | | | | | | | | | | | | | | | | Sorry so much. Reverted: 707bfd5719b76d131152a258d49740165fbafe03. 164637cc3a4e8895ed4ec420e300bd692d3e7812. b9c96c601a8366b75ee8b76d3184ee57379e2620. 21e41af41b52914469885f40155702f325d5c786. 7532f3243ba585f21a8f594d3dc788e38dfa2cb8. 27fb880ab6924ec20ce44aeaeb8d89592c1b91cd. fe340267b0c2082b3af8bc965f7bc0e86d1c3c2c. d9b13d0a74bc0c6dff4bfc61e61a3d7984a0a962. 6737055d165c91904fc04534bee6b9c05c0235b1. 342fed039e53f00ff8758513149f8d41fa3a2e99. 21525bae8801d98ff2f1b52217d7603505ada2d2. b78d86d50727af61e0c4417cf2ef12cbfc73239d. 979de570714d340aaab7a6e99e08d46aa616e7da. f556da10a117396c2c796f6915321b67849f65cd. d8226295e6237a43de33475f798c3c8ac6ac4866. fdab811e58094accc02875c1f83e6476f4598d26.
* A patch renaming equal into eq in the module dealing withGravatar Hugo Herbelin2015-08-02
| | | | | hash-consing, so as to avoid having too many kinds of equalities with same name.
* Adding eq/compare/hash for syntactic view atGravatar Hugo Herbelin2015-08-02
| | | | | | | | | | | | | | | constant/inductive/constructor kernel_name pairs rather than viewing them from only the user or canonical part. Hopefully more uniformity in Constr.hasheq (using systematically == on subterms). A semantic change: Cooking now indexing again on full pairs of kernel names rather than only on the canonical names, so as to preserve user name. Also, in pair of kernel names, ensuring the compact representation is used as soon as both names are the same.
* Followup of 9f81b58551.Gravatar Pierre-Marie Pédrot2015-07-30
| | | | | | The hash function exported by the interface ought to respect the equality. Therefore, we only use the syntactic hash for the hashconsing module while using the canonical hash in the API.
* Fixing bug #4289 (hash-consing only user part of constant notGravatar Hugo Herbelin2015-07-30
| | | | | | | | | | | compatible with a unique bound module name counter which is not synchronous with the backtracking). We changed hash-consing of kernel name pairs to a purely memory management issue, not trying to exploit logical properties such as "syntactically equal user names have syntactically same canonical names" (which is true in a given logical session, but not in memory, at least because of residual values after backtracking).
* Display functions for primitive projections.Gravatar Maxime Dénès2015-07-02
|
* Fixing bug #4190.Gravatar Pierre-Marie Pédrot2015-04-16
| | | | | | | | | | The solution is a bit ugly. In order for two tactic notations identifiers not to be confused by the inclusion from two distinct modules, we embed the name of the source module in the identifiers. This may still fail if the same module is included twice with two distinct parameters, but this should not be possible thanks to the fact any definition in there will forbid the inclusion, for it would be repeated. People including twice the same empty module otherwise probably deserve whatever will arise from it.
* Removing dead code.Gravatar Pierre-Marie Pédrot2015-02-02
|