Moving FStar.Pprint into the (normal, application) library #3582
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This exposes the pretty-printing module for all F* applications by placing it into
FStar.Pprint.fsti
, instead ofFStar.Stubs.Pprint.fsti
. TheFStar.Stubs
namespace is for interacting with compiler internals, which made sense since FStarC_Pprint.ml is the implementation of this module, but prevents normal applications from using pretty printing without bringing in the rest of the compiler.This removes this problem by just making this a normal ulib module. The compile still uses a different version internally, due to needing it in the ML effect, but this does not concern F* application writers.
It also fixes a nasty issue I hadn't noticed where extracting a literal doc was essentially returning
Obj.magic ()
. This is since extraction does not know aboutFStar.Pprint.doc
which is what FStar.Stubs.Pprint (with --codegen OCaml) was translated to, since the FStar.Pprint module doesn't exist. The right thing here, now that FStar and FStarC are distinguished, is drop the Stubs namespace and have an FStarC namespace of interfaces in ulib, avoiding the name wrangling.