-
Notifications
You must be signed in to change notification settings - Fork 356
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
hoon, dojo: initial doccords release #5873
Merged
Merged
Changes from all commits
Commits
Show all changes
141 commits
Select commit
Hold shift + click to select a range
cdaf23a
hoon: prefix and postfix doccords for ++ and +$
drbeefsupreme 336817d
hoon: doccords for core chapters
drbeefsupreme 0a3ec9a
hoon: doccords cleanup %note tag for +boog
drbeefsupreme 41a796d
hoon: hook up $+ for shorthand type rendering
Fang- f08b613
hoon: populate label for %brcn doccords
drbeefsupreme 0dc3498
hoon: change %brdt AST to support doccords label
drbeefsupreme 6437005
hoon: populate %brpt doccords label
drbeefsupreme 1c72ff6
Revert "hoon: change %brdt AST to support doccords label"
drbeefsupreme ff81189
hoon: doccords %brdt cleanup revert
drbeefsupreme c01732d
hoon: doccords wrap bar runes with %notes
drbeefsupreme 2fa0bd3
squash! hoon: doccords wrap bar runes with %notes
drbeefsupreme 37580fa
hoon: doccords for tisfas
drbeefsupreme e50635b
hoon: doccords wrap %rock %sand %wing %knit %bust
drbeefsupreme af7d381
doccords: finding and print doccords library
drbeefsupreme 91aeb0f
doccords: more printing tools
drbeefsupreme 1af2e8f
doccords: dprint library unwrapping hints
drbeefsupreme 752182f
doccords: dprint fix default core arm printing
drbeefsupreme d9e44e9
doccords: dprint print core routine
drbeefsupreme f9dfb59
hoon: turn on hints for %noun types
drbeefsupreme a15711c
doccords: dprint fix crash on non-help %hint
drbeefsupreme edfcceb
doccords: dprint print overview
drbeefsupreme 0c255c1
hoon: plug type leak in vase literals by properly burping %hint
joemfb f7f4b3e
hoon: preserve structural sharing by testing subject/product equality…
joemfb 6a6078b
doccords: dprint core and chapter items
drbeefsupreme 063e3ed
hoon: doccords dist. between arm-doc and prod-doc
drbeefsupreme eb4b996
doccords: dprint can dist. arm-doc and prod-doc
drbeefsupreme 151608d
doccords: dprint fix depth calculation
drbeefsupreme 6f32d10
hoon: doccords wrap tisfas fix
drbeefsupreme 37a7879
doccords: dprint refactoring and renaming
drbeefsupreme 3afc9b6
doccords: dprint all docs in %arm items from type
drbeefsupreme 69399c4
doccords: remove unwrap-note from dprint
drbeefsupreme 877fe00
dojo: add command to lookup doccords
drbeefsupreme 912a502
doccords: flop order of +print-arm results
drbeefsupreme 33b2761
doccords, dojo: move flop print-arm -> dy-inspect
drbeefsupreme 2a57e85
hoon: comment out %note entry in +open
drbeefsupreme 0e8cf3b
doccords: dprint improve default arm core docs
drbeefsupreme 7a94319
dojo, doccords: dprint library can take list term
drbeefsupreme 7d8fabe
doccords: dprint remove +shallow-match
drbeefsupreme b41b22a
doccords: dprint fix chapter printing
drbeefsupreme b023008
doccords: dprint chapter and overview print tweak
drbeefsupreme 24a175a
dojo: flop order of topics for dy-inspect
drbeefsupreme dd71b7c
doccords: dprint debug printfs
drbeefsupreme 3d701f7
doccords: unit tests for arm dox
drbeefsupreme 715d0f3
doccords: unit test for core dox
drbeefsupreme 959906e
doccords: unit test for chapter dox
drbeefsupreme 39ac7cb
Merge branch 'master' into jon/doccords
3d3ea61
hoon: %brcn and %brpt names for doccords
7e0d16d
dprint: new core naming syntax
6e02e35
dprint: fix issues with core types
0972c85
dprint: arms calling other arms dont steal doccord
a3ddde7
dprint: compile default arm in core against core
605960e
dprint: simplify and fix core/chapter/arm search
f7d0d3e
dprint: missed |^ in last commit
693226b
dprint: deduplicate role of +signify
62716ff
dprint: name core containing types
f31a9ed
dprint: swap expected<->actual order in unit tests
a59bd02
hoon: doccords, product-docs arent made in +boog
8f0bc30
dprint: help from hint uses second type, pass test
832d483
dprint: cleanup some logic around %hint types
a8e28cc
dprint: remove chapter-id from %chapter item
8cb392f
dprint: comment for library
d0b8d28
hoon: add %dict tag to %spec for doccords
552b8e9
hoon: spec doccord parsing, refactor +till +tall
6f66a6d
pprint: add %dict tag
941ff18
hoon: refactor doccord parsing for +tall and +till
8f946ed
dojo: print %help hints with ??
8cd919b
dojo: ?? pattern matches on %hint types
efe01b8
hoon: batch comment doccords inside of cores
8f48f08
dprint: change to batch comment syntax
77b5c73
hoon: fix batch comment parsing for ++ $ arms
72dec14
dprint: update default core arm comment syntax
5b65288
dprint: add styled text first run
4b8cdd6
dprint: easier to read style changes
69b06e0
dprint: add identifying glyphs to various items
0f8f90c
dprint: simplify type to item interface
b4d0444
dprint: add missing doccords
b3e6f82
dojo: change doccords syntax to be path-like
97d183b
Merge branch 'master' into jon/doccords
5710826
dprint: fix test library argument
37ce546
dprint: simplify arm doc testing
3bfad48
hoon: fix batch comment parser
2028ae9
dprint: batch comment tests, more refactoring
274bc16
dprint: remove erroneous sigpam
b80590f
hoon: remove _docs-engine
de19456
hoon: revamp doccords parsing for batch comments
a4ca510
dprint: fix syntax and test suite for new parser
1cd95a9
hoon: add +$ cuff (list link)
27135f1
dprint: links -> cuff
938dc8c
dojo: reverse doccords query ordering
37343b6
doccords: add sample library lib/deco.hoon
948bd1e
doccords: adds batch comment examples to lib/deco
862f6cc
doccords: update language in lib/deco
4dd8b4d
doccords: change :: in lib/deco to :>
b7412d9
doccords: lib/deco remove informal comment
ef9297c
doccords: these <-> other locations
73c0222
doccords: deco convention for +$ arms
c295123
doccords: deco remove double comment
49420e2
hoon: refactor %brcn %brpt optional arg parsing
5fc3b3f
hoon, dprint: change doccords syntax to ::
bd69f09
gen: add todo item to +help for doccords
f4a84ca
hoon, dprint: remove |% and |@ core names
c11d11e
deco: revision to account for :: doccords syntax
618fc0f
Merge branch 'next/arvo' into jon/doccords
06a7daa
hoon: change %dict spec to %gist
244d0d2
hoon: change apse:docs to parse as a $note
64f6430
dprint: +find-item-in-type core name=summary
1a69393
dprint: arms that build cores return core items
1fed185
dprint: refactor +find-item-in-type &co
387ae3e
hoon: remove +vil
df45bfb
hoon: ~master-morzod comments on doccords
0fbdd68
dprint: refactor some printing logic
ec74127
dprint: dont print (undocumented) on arms
f519b4c
hoon: fix sig rune whitespace to allow doccords
ca3140a
hoon: doccord parsing fixes
baa4894
hoon: rune parser whitespace changes for docs
3c32378
hoon: make some comments into doccords
2f4b716
dprint: fixes and refactoring of _hunt, signatures
0ed484a
hoon: +seam and +scye doccords edit
4afdfdb
hoon: remove unused $links
ce209fc
hoon: %gist spec doccords are tagged
3b6f0f5
hoon: remove comment on batch arm docs above chap
75cf230
hoon: revise doccord intermediate parse structures
b76134f
hoon: attach all untagged arm docs
627827f
hoon: revise leap:docs and apse:docs
fc8449d
dprint: add casting to some _hunt arms
d508c8c
hoon: add comment about .nut in +ax
a350b12
dprint: uncomment chapter names in _hunt
25dba7e
hoon: remove extra hoon casts in +decorate
68c2ab5
hoon: fix .nut comment
44aa90c
hoon: remove +hint:ax
e04262e
hoon: swap ?. for ?: on +loaf and +loan
835428d
dprint: cut off signatures of length >= 3
4d08400
dprint: call $ arms $ arms
d7edbd6
hoon: doccordsify hoon.hoon comments
d5bf903
Merge branch 'next/arvo' into jon/doccords
5b99f74
hoon: remove deprecated lustar parser
0119eef
Merge branch 'next/arvo' into jon/doccords
philipcmonk cdaae65
dojo: mule calls to doccords
philipcmonk a7a3790
kelvin: bump to 139
philipcmonk 40451fa
Revert "Revert "Merge pull request #6039 from tadad/da/apt-in""
philipcmonk 0791c45
hoon: put doccords behind parser flag
philipcmonk File filter
Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
There are no files selected for viewing
Git LFS file not shown
This file contains 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
This file contains 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
This file contains 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
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,189 @@ | ||
:: Hoon doccords sample | ||
:: | ||
:: this is a sample file designed to explain syntax and conventions | ||
:: for doccords | ||
:: | ||
:: all lines must be under 80 characters. no blank lines. | ||
:: any line longer than 60 characters is probably too long. | ||
:: uppercase or non-ascii letters are strongly discouraged. | ||
:: | ||
:: whenever possible, use formal decorations. {::} decorates | ||
:: the next expression when put on its own line, and the previous | ||
:: expression if written on the same line | ||
:: | ||
:: there are two places to put decorations: in line with the | ||
:: code, and on the right margin. | ||
:: | ||
:: the file below is a well-commented library, built around | ||
:: a typical two-core structure. the cores are labeled {%arch} | ||
:: (structures) and {%work} (productions). | ||
:: | ||
:: this code is written to display the variety of formatting | ||
:: options the parser allows. a specific convention should pick | ||
:: one of these styles and stick to it. | ||
:: | ||
:: there are three ways to mark the beginning of a formal comment: | ||
:: 1- {:: $foo:} | ||
:: 2- {:: +bar:} | ||
:: 3- {:: } | ||
:: | ||
:: style 1 may optionally be followed by a series of paragraphs, where each | ||
:: paragraph is preceded by a line containing only {::} and whitespace, and | ||
:: each line of a given paragraph is preceded by four aces. | ||
:: {::} | ||
:: {:: more text} | ||
:: {:: even more text} | ||
:: {::} | ||
:: {:: |=(code=hoon !!)} | ||
:: | ||
:: style 2 is much like style 1, but paragraphs are indented by two spaces | ||
:: instead of four. | ||
:: {::} | ||
:: {:: more text} | ||
:: {:: even more text} | ||
:: {::} | ||
:: {:: |=(code=hoon !!)} | ||
:: | ||
:: code is indented a total of six aces, for either style. | ||
:: | ||
:: style 3 is used to annotate the hoon or spec that immediately follows | ||
:: the comment. paragraphs are written with style 2. | ||
:: | ||
:: the $foo and +bar above are examples of *lexical locations* for | ||
:: style and batch-commenting purposes. this tells the parser to attempt | ||
:: to attach the comment to the specified location. these locations | ||
:: may be written as follows: | ||
:: - `|foo` means a chapter | ||
:: - `%foo` means a constant | ||
:: - `.foo` means a face | ||
:: - `+foo` means an arm | ||
:: - `$foo` means a spec | ||
:: - `^foo` means a core | ||
:: - `_foo` means a door | ||
:: - `=foo` means a gate | ||
:: - `/foo` means a file path segment | ||
:: | ||
:: thus /lib/foo^widget|initial=open means the =open gate in the |initial | ||
:: chapter of the ^widget core in the /foo library | ||
:: | ||
:: at present, doccords does not support lexical locations in full. | ||
:: only single-element locations of the form `$foo` and `+foo` are supported, | ||
:: and must be written above an arm in the core to which they are to be | ||
:: attached, and after the chapter they are in (if the core has chapters). | ||
:: you may still write doccords for other locations in anticipation of the | ||
:: fully supported lexical location, but they will be thrown away before they | ||
:: make it to the compiler. | ||
:: | ||
:: a postfix formal comment will either attach to hoon or spec on the | ||
:: current line, or the arm name if there is no hoon or spec on the | ||
:: line. the convention for +$ arms is that the comment attached to the | ||
:: arm is about the mold itself, while the comment attached to the spec | ||
:: is about the output type of the mold. | ||
:: | ||
:: to inspect doccords in this file from dojo, try the following: | ||
:: | ||
:: > =deco -build-file %/lib/deco/hoon | ||
:: > # deco | ||
:: > # deco/arch | ||
:: > # deco/arch/molds | ||
:: > # deco/arch/molds/goof | ||
:: | ||
:: > ?? *goof:deco | ||
:: | ||
=> :: | ||
:: structures for our imaginary hello, world generator. | ||
:: | ||
:: nothing forces us to put structures in a separate core. | ||
:: but compile-time evaluation doesnt work in the current | ||
:: core; we often want to statically evaluate structures. | ||
:: | ||
:: there are three kinds of structures: moldss (normalizing | ||
:: functions), mold builders (functions that build molds), and | ||
:: constants (static data). | ||
:: | ||
:: most code will not need its own mold builders. but put them | ||
:: in a separate chapter (separated by {+|}). | ||
|% | ||
:: molds are functions that normalize nouns. | ||
:: | ||
:: arms producing molds are introduced with {+$}. the | ||
:: compiler will copy the arm decoration onto its product | ||
+| %molds | ||
:: $jam: some delicious jam | ||
:: $jelly: different from jam? | ||
+$ spot [p=@ q=@] :: a coordinate | ||
+$ tops :: mold for coordinate | ||
[p=@ q=@] :: another coordinate | ||
+$ goof :: a simple tuple mold | ||
$: foo=@ :: something mysterious | ||
bar=@ :: go here for drink | ||
moo=(binary-tree juice) :: cows do this | ||
== | ||
+$ juice :: fruity beverage mold | ||
$% [%plum p=@] :: fresh prune | ||
[%pear p=@ q=@] :: good for cider | ||
[%acai p=@] :: aztec superfood | ||
== | ||
+$ jam @tas | ||
+$ jelly @tas | ||
:: mold builders are functions that build molds from other molds | ||
:: | ||
:: other languages might call these "type constructors" | ||
:: or "higher-kinded types". | ||
+| %mold-builders | ||
++ binary-tree :: tree mold builder | ||
|* a=$-(* *) | ||
$@(~ [n=a l=(binary-tree a) r=(binary-tree a)]) | ||
:: | ||
:: if you have constants, put them in their own chapter. | ||
+| %constant | ||
++ answer :: answer to everything | ||
42 | ||
-- | ||
:: engines for our imaginary hello, world app. | ||
:: | ||
|% | ||
:: +default-jam: bunts $jam | ||
:: +default-juice: bunts $juice | ||
++ say-hello :: say hi to someone | ||
:: friendly welcome message | ||
:: | ||
|= | ||
:: .txt: friend to say hi to | ||
:: | ||
txt=term | ||
^- tape | ||
"hello, {(rip 3 txt)}" | ||
:: +say-goodbye: say a really proper goodbye | ||
:: | ||
:: some paragraphs about the goodbye algorithm, possibly | ||
:: including code indented by four extra spaces: | ||
:: | ||
:: ?: =(%hello %world) | ||
:: %hello | ||
:: %world | ||
:: | ||
++ say-goodbye | ||
:: describe product of function | ||
:: | ||
|= | ||
:: .txt: departing friend | ||
:: .num: number of friends | ||
$: txt=term | ||
num=@ | ||
== | ||
^- tape | ||
:: .foo: four | ||
:: .bar: forty-two | ||
=/ foo (add 2 2) | ||
=/ bar (add (mul num foo) 2) | ||
=/ moo (mul num bar) :: for all the cows | ||
"goodbye and {(scow %ud moo)}, {(rip 3 txt)}" | ||
:: | ||
++ say-minimum :: minimal decoration | ||
|= txt=term | ||
"nothing to say to {(rip 3 txt)}" | ||
:: | ||
++ default-jam *jam | ||
++ default-juice *juice | ||
-- |
Oops, something went wrong.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Playing
%hold
s (i.e. what we're doing here, not sure if there's an accepted term for this) all throughout a typeoften just crashes. Is there a better option? I suppose it could just give up after some chosen depth, but that isn't really user friendly. It ought to "just work". Besides limiting by depth, the only other idea I have is Clay or dojo building a cache of doccords. I don't know much about caches though, so that's just spitballing. A cache is outside of the scope, but a depth limit is easy.
It seems wrong to ship a feature that has such a high chance of crashing.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since addressing this sort of issue is one of the main goals of the doccords apprenticeship, my opinion now is that its fine to ship this since its an experimental feature seeking a good interface, and its fine to have pain points in the first attempt at an interface.