Add initial documentation in JSON format#4
Open
schoen wants to merge 2 commits intoBlockstreamResearch:masterfrom
Open
Add initial documentation in JSON format#4schoen wants to merge 2 commits intoBlockstreamResearch:masterfrom
schoen wants to merge 2 commits intoBlockstreamResearch:masterfrom
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
As I mentioned on the call this morning, I made documentation for @stringhandler's initial standard library work.
This is based on #3 and adds some (also machine-generated, in this case from a Python script) documentation in the format of a JSON file. This corresponds to the format of
elements.jsonin the existing SimplicityHL documentation environment.The goal of this is to generate markdown for the docs site and also to import this in the LSP so that that the LSP can provide pop-up documentation for standard library functions.
Outstanding questions that we should address (either before or after merging this is OK with me):
(1) Should this routinely be autogenerated and should the Python script I wrote be checked into the repository? Should the standard library code itself also be autogenerated or should either or both of them be statically updated?
(2) Should it somehow reference the individual files within the standard library which @stringhandler has used in #3? E.g.
typesandassert? Should those be used as section names?(3) This process showed me that #3 is missing
assert_eq128andeq_ctx8. There is also something weird with the newlines such that some forms ofgrepdon't always work (do we need to normalize what kind of text file each.simffile is committed as or something)?(4) What should we sort functions by in the documentation?
(5) Any reason that
orandnotare defined butandisn't?(6) Any chance of getting the infix operators merged instead of defining
orandnothere at all? Many languages don't have separate functions for boolean operators that are defined via infix notations.