Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Serialization and deserialization of kernel terms and their environments #119

Open
palmskog opened this issue Mar 11, 2019 · 8 comments
Open

Comments

@palmskog
Copy link
Collaborator

palmskog commented Mar 11, 2019

We want to be able to serialize and deserialize environments with elaborated and fully typed kernel terms (Constr.t). More specifically, we want to be able to serialize (relevant data from) .vo files via the command line, and then be able to separately check the results.

Tasks:

  • add all the necessary annotations to enable kernel term serialization, following 454815f and [serlib] add partial support for serializing Env #118
  • introduce a new "format" .kenv that drops many unnecessary parts of .vo files, but can still be sent to the checker
  • extend sercomp with a new option --mode=env that takes a .vo or (even .v?) file as input and outputs sexps according to .kenv [for producing serialized kernel terms]
  • extend sercomp to support the .kenv format with the --mode=check option [for checking serialized kernel terms]
  • construct a small example with non-trivial terms that doesn't require the Coq prelude
@ejgallego
Copy link
Owner

What do you think of #111 ? Maybe we should just have a single binary with --input and --output modes?

@palmskog
Copy link
Collaborator Author

palmskog commented Mar 11, 2019

I think it's fine if we merge sercomp/compser, as long as we can provide a simple mapping, e.g., compser --mode=check f.sexp is equivalent to sercomp --input=sexp --output=check f.sexp. Maybe we keep --mode and just add --input?

@palmskog
Copy link
Collaborator Author

palmskog commented Mar 11, 2019

If I'm not mistaken, we are aiming to have four forms of input to sercomp:

  • regular vernacular (.v files): vernac(?)
  • sexp-serialized vernacular: sexp(?)
  • OCaml-serialized kernel terms + data (.vo files): vo
  • sexp-serialized kernel environments: kenv

@palmskog palmskog changed the title Serialization and deserialization of kernel terms Serialization and deserialization of kernel terms and their environments Mar 12, 2019
ejgallego added a commit to yangky11/coq-serapi that referenced this issue Mar 13, 2019
This commit adds preliminary support for kernel environments, mainly
addressing the global maps; some comments:

- We have to override the problem of private types using Obj.magic,
  this will imply another cut and paste when we upgrade Coq.

- We don't support 2-way serialization yet due to `Environ.env` being
  a private type, we'll have to do as above.

- We start to add some more interesting types w.r.t. serialization,
  including a `SerType` interface and a map functor.

- We are still missing serialization of the universe map, and some
  other minor stuff.

c.f. ejgallego#119

Co-authored-by: Kaiyu Yang <kaiyuy@cs.princeton.edu>
@ejgallego
Copy link
Owner

#118 is ready, however there are still some parts missing; in particular:

  • UGraph.t: essential
  • Conv_oracle.oracle: I am not sure how important this is for type-checking / roundtrip
  • Declarations.module_retroknowledge: shouldn't matter a lot [I hope]
  • Mod_subst.delta_resolver: this seems important
  • Univ.ContextSet.t: Pretty important too,
  • Cemitcodes.to_patch_substituted: VM stuff, can be ignored for now,
  • Mod_subst.substituted: No idea,

Good news is that most of the missing stuff can be done in parallel now.

Another problem is that Environ.environ is a private type, but Object.magic plus some cut and paste should save us like in the case for globals.

ejgallego added a commit to yangky11/coq-serapi that referenced this issue Mar 13, 2019
This commit adds preliminary support for kernel environments, mainly
addressing the global maps; some comments:

- We have to override the problem of private types using Obj.magic,
  this will imply another cut and paste when we upgrade Coq.

- We don't support 2-way serialization yet due to `Environ.env` being
  a private type, we'll have to do as above.

- We start to add some more interesting types w.r.t. serialization,
  including a `SerType` interface and a map functor.

- We are still missing serialization of the universe map, and some
  other minor stuff.

c.f. ejgallego#119

Co-authored-by: Kaiyu Yang <kaiyuy@cs.princeton.edu>
@ejgallego
Copy link
Owner

We also need to add the dumping option, but indeed I am thinking if it wouldn't make more sense a fine env-manipulation API. The whole env is really big I'm afraid.

For now we can see it using the (Query () Env) command.

@ejgallego
Copy link
Owner

I am realizing that we have a bit of a problem with the current "round-trip" idea.

The env type in Coq is private, so indeed it means that it is not meant to be fed to the type checker. We could do a roundtrip, but the kernel doesn't have the ability to check and env back; the env is supposed to be already checked.

So indeed they only way we can make the kernel check something is using a function such as:

val add_constant
  :  in_section:bool
  -> Label.t
  -> global_declaration
  -> env
  -> Constant.t * env

which basically extends env with the corresponding Declarations.constant_body. The input data is a bit different, in particular, it is of type Entries.definition_entry, which is the "unchecked" constant data.

Ummm, maybe this would be a good moment to schedule a call and discuss a bit more.

@palmskog
Copy link
Collaborator Author

No matter how the roundtrip will work in the end, I think we can at least go ahead and add an option to sercomp to serialize environments, so our side can understand a bit better what's going on. For example, in sercomp.ml, does it make sense to serialize the "final" environment:

let close_document ~mode ~doc ~in_file =
  let open Sertop_arg in
  match mode with
  | C_parse -> ()
  | C_sexp  -> ()
  | C_print -> ()
  | C_stats ->
    Sercomp_stats.print_stats ()
  | C_env ->
   (* ??? *)
  | C_check ->
    let _doc = Stm.join ~doc in
    check_pending_proofs ()
  | C_vo ->
    let _doc = Stm.join ~doc in
    check_pending_proofs ();
    let ldir = Stm.get_ldir ~doc in
    let out_vo = Filename.(remove_extension in_file) ^ ".vo" in
    Library.save_library_to ldir out_vo (Global.opaque_tables ())

@ejgallego
Copy link
Owner

Sure, done in #126

ejgallego added a commit to ejgallego/opam-repository that referenced this issue Apr 23, 2019
CHANGES:

* [serapi ] Add `Parse` command to parse a sentence; c.f.
             ejgallego/coq-serapi#117
             (@ejgallego) (cc: @yangky11)
 * [sercomp] Add "print" `--mode` to print the input Coq document
             (@ejgallego) (cc: @Ptival)
 * [serlib ] Serialize `Universe.t` (@ejgallego, request by @yangky11)
 * [sercomp] Merge `sercomp` and `compser`, add `--input` parameter to `sercomp`
             (@palmskog) (cc: @ejgallego)
 * [serlib ] Much improved support for serialization of `Environ.env`
             (@yangky11 and @ejgallego c.f. ejgallego/coq-serapi#118)
 * [serapi ] Make sure every command ends with `Completed`, even if it produced
             an exception (@brando90 and @ejgallego c.f. ejgallego/coq-serapi#124)
 * [sercomp] Add `--mode=kexp` to output the final kernel environment.
             (@ejgallego c.f. ejgallego/coq-serapi#119)
 * [serlib ] Serialize more internal environment fields (@ejgallego c.f. ejgallego/coq-serapi#119)
 * [serlib ] Improvements in serialization org (@ejgallego)
 * [serlib ] Serialize kernel entries (@ejgallego @palmskog)
 * [serlib ] Fix critical bug on `Constr` deserialization; reported by @palmskog,
             fix by @SkySkimmer.
 * [sertop]  Fix backtrace printing when using `--debug` (@ejgallego)
 * [serlib ] Don't serialize VM values (@ejgallego, bug report by @palmskog)
 * [serapi ] Output location on tokenization (@ejgallego , idea by @palmskog)
 * [serapi ] Add basic documentation of the protocol (@ejgallego cc ejgallego/coq-serapi#109)
@ejgallego ejgallego added this to the 0.7.0 milestone Apr 23, 2019
@ejgallego ejgallego modified the milestones: 0.7.0, 0.8.0 Oct 25, 2019
@ejgallego ejgallego modified the milestones: 0.11.0, 0.11.1 May 13, 2020
@ejgallego ejgallego modified the milestones: 0.11.1, 0.12.1 May 27, 2020
@ejgallego ejgallego modified the milestones: 0.12.1, 0.13.1 Mar 12, 2021
@ejgallego ejgallego modified the milestones: 0.13.1, 0.14.0 Sep 21, 2021
@ejgallego ejgallego removed this from the 0.14.0 milestone Jun 15, 2022
@ejgallego ejgallego added this to the 0.16.0 milestone Jun 15, 2022
@ejgallego ejgallego removed this from the 0.16.0 milestone Sep 8, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants