Urbit Docs
  • What is Urbit?
  • Get on Urbit
  • Build on Urbit
    • Contents
    • Environment Setup
    • Hoon School
      • 1. Hoon Syntax
      • 2. Azimuth (Urbit ID)
      • 3. Gates (Functions)
      • 4. Molds (Types)
      • 5. Cores
      • 6. Trees and Addressing
      • 7. Libraries
      • 8. Testing Code
      • 9. Text Processing I
      • 10. Cores and Doors
      • 11. Data Structures
      • 12. Type Checking
      • 13. Conditional Logic
      • 14. Subject-Oriented Programming
      • 15. Text Processing II
      • 16. Functional Programming
      • 17. Text Processing III
      • 18. Generic and Variant Cores
      • 19. Mathematics
    • App School I
      • 1. Arvo
      • 2. The Agent Core
      • 3. Imports and Aliases
      • 4. Lifecycle
      • 5. Cards
      • 6. Pokes
      • 7. Structures and Marks
      • 8. Subscriptions
      • 9. Vanes
      • 10. Scries
      • 11. Failure
      • 12. Next Steps
      • Appendix: Types
    • App School II (Full-Stack)
      • 1. Types
      • 2. Agent
      • 3. JSON
      • 4. Marks
      • 5. Eyre
      • 6. React app setup
      • 7. React app logic
      • 8. Desk and glob
      • 9. Summary
    • Core Academy
      • 1. Evaluating Nock
      • 2. Building Hoon
      • 3. The Core Stack
      • 4. Arvo I: The Main Sequence
      • 5. Arvo II: The Boot Sequence
      • 6. Vere I: u3 and the Serf
      • 7. Vere II: The Loom
      • 8. Vanes I: Behn, Dill, Kahn, Lick
      • 9. Vanes II: Ames
      • 10. Vanes III: Eyre, Iris
      • 11. Vanes IV: Clay
      • 12. Vanes V: Gall and Userspace
      • 13. Vanes VI: Khan, Lick
      • 14. Vanes VII: Jael, Azimuth
    • Runtime
      • U3
      • Conn.c Guide
      • How to Write a Jet
      • API Overview by Prefix
      • C in Urbit
      • Cryptography
      • Land of Nouns
    • Tools
      • Useful Links
      • JS Libraries
        • HTTP API
      • Docs App
        • File Format
        • Index File
        • Suggested Structure
    • Userspace
      • Command-Line App Tutorial
      • Remote Scry
      • Unit Tests
      • Software Distribution
        • Software Distribution Guide
        • Docket File
        • Glob
      • Examples
        • Building a CLI App
        • Debugging Wrapper
        • Host a Website
        • Serving a JS Game
        • Ship Monitoring
        • Styled Text
  • Urbit ID
    • What is Urbit ID?
    • Azimuth Data Flow
    • Life and Rift
    • Urbit HD Wallet
    • Advanced Azimuth Tools
    • Custom Roller Tutorial
    • Azimuth.eth Reference
    • Ecliptic.eth Reference
    • Layer 2
      • L2 Actions
      • L2 Rollers
      • L2 Roller HTTP RPC-API
      • L2 Transaction Format
  • Urbit OS
    • What is Urbit OS?
    • Base
      • Hood
      • Threads
        • Basics Tutorial
          • Bind
          • Fundamentals
          • Input
          • Output
          • Summary
        • HTTP API Guide
        • Spider API Reference
        • Strandio Reference
        • Examples
          • Child Thread
          • Fetch JSON
          • Gall
            • Poke Thread
            • Start Thread
            • Stop Thread
            • Take Facts
            • Take Result
          • Main-loop
          • Poke Agent
          • Scry
          • Take Fact
    • Kernel
      • Arvo
        • Cryptography
        • Move Trace
        • Scries
        • Subscriptions
      • Ames
        • Ames API Reference
        • Ames Cryptography
        • Ames Data Types
        • Ames Scry Reference
      • Behn
        • Behn API Reference
        • Behn Examples
        • Behn Scry Reference
      • Clay
        • Clay API Reference
        • Clay Architecture
        • Clay Data Types
        • Clay Examples
        • Clay Scry Reference
        • Filesystem Hierarchy
        • Marks
          • Mark Examples
          • Using Marks
          • Writing Marks
        • Using Clay
      • Dill
        • Dill API Reference
        • Dill Data Types
        • Dill Scry Reference
      • Eyre
        • EAuth
        • Eyre Data Types
        • Eyre External API
        • Eyre Internal API
        • Eyre Scry Reference
        • Low-Level Eyre Guide
        • Noun channels
      • Gall
        • Gall API Reference
        • Gall Data Types
        • Gall Scry Reference
      • Iris
        • Iris API Reference
        • Iris Data Types
        • Iris Example
      • Jael
        • Jael API Reference
        • Jael Data Types
        • Jael Examples
        • Jael Scry Reference
      • Khan
        • Khan API Reference
        • Khan Data Types
        • Khan Example
      • Lick
        • Lick API Reference
        • Lick Guide
        • Lick Examples
        • Lick Scry Reference
  • Hoon
    • Why Hoon?
    • Advanced Types
    • Arvo
    • Auras
    • Basic Types
    • Cheat Sheet
    • Cryptography
    • Examples
      • ABC Blocks
      • Competitive Programming
      • Emirp
      • Gleichniszahlenreihe
      • Islands
      • Luhn Number
      • Minimum Path Sum
      • Phone Letters
      • Restore IP
      • Rhonda Numbers
      • Roman Numerals
      • Solitaire Cipher
      • Water Towers
    • Generators
    • Hoon Errors
    • Hoon Style Guide
    • Implementing an Aura
    • Irregular forms
    • JSON
    • Limbs and wings
      • Limbs
      • Wings
    • Mips (Maps of Maps)
    • Parsing Text
    • Runes
      • | bar · Cores
      • $ buc · Structures
      • % cen · Calls
      • : col · Cells
      • . dot · Nock
      • / fas · Imports
      • ^ ket · Casts
      • + lus · Arms
      • ; mic · Make
      • ~ sig · Hints
      • = tis · Subject
      • ? wut · Conditionals
      • ! zap · Wild
      • Constants (Atoms and Strings)
      • --, == · Terminators
    • Sail (HTML)
    • Serialization
    • Sets
    • Standard Library
      • 1a: Basic Arithmetic
      • 1b: Tree Addressing
      • 1c: Molds and Mold-Builders
      • 2a: Unit Logic
      • 2b: List Logic
      • 2c: Bit Arithmetic
      • 2d: Bit Logic
      • 2e: Insecure Hashing
      • 2f: Noun Ordering
      • 2g: Unsigned Powers
      • 2h: Set Logic
      • 2i: Map Logic
      • 2j: Jar and Jug Logic
      • 2k: Queue Logic
      • 2l: Container from Container
      • 2m: Container from Noun
      • 2n: Functional Hacks
      • 2o: Normalizing Containers
      • 2p: Serialization
      • 2q: Molds and Mold-Builders
      • 3a: Modular and Signed Ints
      • 3b: Floating Point
      • 3c: Urbit Time
      • 3d: SHA Hash Family
      • 3e: AES encryption (Removed)
      • 3f: Scrambling
      • 3g: Molds and Mold-Builders
      • 4a: Exotic Bases
      • 4b: Text Processing
      • 4c: Tank Printer
      • 4d: Parsing (Tracing)
      • 4e: Parsing (Combinators)
      • 4f: Parsing (Rule-Builders)
      • 4g: Parsing (Outside Caller)
      • 4h: Parsing (ASCII Glyphs)
      • 4i: Parsing (Useful Idioms)
      • 4j: Parsing (Bases and Base Digits)
      • 4k: Atom Printing
      • 4l: Atom Parsing
      • 4m: Formatting Functions
      • 4n: Virtualization
      • 4o: Molds
      • 5a: Compiler Utilities
      • 5b: Macro Expansion
      • 5c: Compiler Backend & Prettyprinter
      • 5d: Parser
      • 5e: Molds and mold builders
      • 5f: Profiling support
    • Strings
    • The Engine Pattern
    • Udon (Markdown-esque)
    • Vases
    • Zuse
      • 2d(1-5): To JSON, Wains
      • 2d(6): From JSON
      • 2d(7): From JSON (unit)
      • 2e(2-3): Print & Parse JSON
      • 2m: Ordered Maps
  • Nock
    • What is Nock?
    • Decrement
    • Definition
    • Fast Hints and Jets
    • Implementations
    • Specification
  • User Manual
    • Contents
    • Running Urbit
      • Cloud Hosting
      • Home Servers
      • Runtime Reference
      • Self-hosting S3 Storage with MinIO
    • Urbit ID
      • Bridge Troubleshooting
      • Creating an Invite Pool
      • Get an Urbit ID
      • Guide to Factory Resets
      • HD Wallet (Master Ticket)
      • Layer 2 for planets
      • Layer 2 for stars
      • Proxies
      • Using Bridge
    • Urbit OS
      • Basics
      • Configuring S3 Storage
      • Dojo Tools
      • Filesystem
      • Shell
      • Ship Troubleshooting
      • Star and Galaxy Operations
      • Updates
Powered by GitBook

GitHub

  • Urbit ID
  • Urbit OS
  • Runtime

Resources

  • YouTube
  • Whitepaper
  • Awesome Urbit

Contact

  • X
  • Email
  • Gather
On this page
  • |$ "barbuc"
  • |_ "barcab"
  • |: "barcol"
  • |% "barcen"
  • |. "bardot"
  • |^ "barket"
  • |- "barhep"
  • |~ "barsig"
  • |* "bartar"
  • |= "bartis"
  • |@ "barpat"
  • |? "barwut"
Edit on GitHub
  1. Hoon
  2. Runes

| bar · Cores

Core expressions produce cores. A core is a cell of [battery payload]. The battery is code, a battery of Nock formulas. The payload is the data needed to run those formulas correctly.

Five core runes (|=, |., |-, |*, and |$) produce a core with a single arm, named $. As with all arms, we can recompute $ with changes, which is useful for recursion among other things.

|$ "barbuc"

Declares a mold builder wet gate with one or more molds as its sample.

Syntax

Two arguments, fixed.

|$  sample
body
|$(sample body)

None

AST

[%brbc sample=(lest term) body=spec]

Expands to

|$  [a b]
body

becomes

|*  [a=$~(* $-(* *)) b=$~(* $-(* *))]
^:
body

Semantics

|$ is used to declare a wet gate mold builder that is polymorphic in its input molds. a is a lest of term used as identifiers for the input molds. b is a structure built from elements of a. The output of |$ is a mold builder obtained by substituting the input molds parameterized by a into b.

Discussion

A mold builder is a wet gate from one or more molds to a mold. A mold is a function from nouns to nouns with types that may be partial, is always idempotent, and usually the identity function on the noun itself.

|$ is a restricted form of |*. The use of |$ over |* is one of style, as either could be used to make wet gates that are mold builders. The buc in |$ is a hint that |$ is closely related to buc runes, and thus |$ should be used to make mold builders, while |* should be used for any other sort of wet gate. Unlike |*, the body of |$ is parsed in pattern mode to a $spec. Thus, the second argument of |$ is frequently a buc rune. For further discussion of wet gates, see the entry for |*.

Like other single-arm cores, the arm for |$ is named $ and this can be used to define recursive structures. Note however that Hoon is evaluated eagerly, and so infinite structures are not permitted.

Proper style for |$ is to enclose the first argument with brackets, even if it is only a single term. The interpeter will accept a single term without brackets just fine, but this style is for consistency with the fact that the first argument is a lest.

Examples

> =foo |$([a b] [b a])

> =bar (foo [@ @tas])

> (bar %cat 3)
[%cat 3]

|_ "barcab"

Produce a door (a core with a sample).

Syntax

One fixed argument, then a variable number of +-family expressions.

|_  a=spec
++  b=term  c=hoon
++  d=term  e=hoon
     ...
++  f=term  g=hoon
--

None

None

Note: The ++ rune may be replaced with any other rune in the + family.

AST

[%brcb p=spec q=alas r=(map term tome)]

Expands to

=|  a=spec
|%
++  b=term  c=hoon
++  d=term  e=hoon
       ...
++  f=term  g=hoon
--

Semantics

The product of a |_ expression is a door, a core with one or more arms whose payload includes a sample. That is, a door is a cell of [battery [sample context]], where the battery contains one or more arms.

a defines the door sample type and usually includes a name assignment (e.g., n=@). a is followed by a series of arm definitions, each of which begins with a rune in the + family (most of ++). There must be at least one arm, but there may be arbitrarily many. Each arm must include a name (b, d, and f above), which is followed by the expression (c, e, and g above) that defines the arm product.

The context of the door is the subject of the |_ expression.

Discussion

A door is the general case of a gate (function). A gate is a door with only one arm, which has the name $.

Calling a door is like calling a gate except the caller also needs to specify the arm to be computed. So, for example, if you have some door door which contains some arm arm, and you want to pass some argument (i.e., input value arg), you would call it with ~(arm door arg).

Because gates are also doors, you can call them the same way. To call the gate foo as a door, instead of (foo baz) we would write ~($ foo baz). This is an irregular form for %~($ foo baz), %~.

Examples

A trivial door:

> =mol |_  a=@ud
       ++  succ  +(a)
       ++  prev  (dec a)
       --

> ~(succ mol 1)
2

> ~(succ mol ~(succ mol ~(prev mol 5)))
6

A more interesting door, from the kernel library:

++  ne
  |_  tig=@
  ++  d  (add tig '0')
  ++  x  ?:((gte tig 10) (add tig 87) d)
  ++  v  ?:((gte tig 10) (add tig 87) d)
  ++  w  ?:(=(tig 63) '~' ?:(=(tig 62) '-' ?:((gte tig 36) (add tig 29) x)))
  --

The ne door prints a digit in base 10, 16, 32 or 64:

~zod:dojo> `@t`~(x ne 12)
'c'

|: "barcol"

Produce a gate with a custom sample.

Syntax

Two arguments, fixed.

|:  a
b
|:(a b)

None

AST

[%brcl p=hoon q=hoon]

Semantics

a is a Hoon expression whose product type defines which values the gate accepts, and it usually includes a name (e.g., n=1). The product of a also serves as the default value of the sample. b is a Hoon expression that determines the product value of the gate.

Expands to

=+  a
|.  b

Discussion

Pick your own default value for the sample. Note that a is an ordinary expression, not a type; |: doesn't bunt a sample as |= does.

This is useful if you want a gate to have a sample of a particular type, but you don't want the default value of the gate to be the default value of that type.

Examples

> =add-ten |:(n=`@`2 (add n 10))

> (add-ten 10)
20

> (add-ten)
12

|% "barcen"

Produce a core, [battery payload].

Syntax

Argument: a variable number of +-family expressions.

|%
++  a=term  b=hoon
++  c=term  d=hoon
     ...
++  e=term  f=hoon
--

None

None

Note: The ++ rune may be replaced with any other rune in the + family.

AST

[%brcn p=(unit term) q=(map term tome)]

Semantics

The product of a |% expression is a dry core with one or more arms in the battery.

The |% rune is followed by a series of arm definitions, each of which begins with a rune in the + family (most of ++). There must be at least one arm, but there may be arbitrarily many. Each arm must include a name (a, c, and e above), which is followed by the expression (b, d, and f above) that defines the arm product.

The core payload is the subject of the |% expression.

Discussion

A core is a cell of [battery payload], where the battery is code and the payload is data. The battery is one or more arms. An arm is a computation that takes the core itself as its subject.

The |% rune is used to construct a core from a series of arm definitions. Each arm definition in the expression begins with an arm rune (++, +$, or +*). These arms make up the battery. The subject of the |% expression is used to make the core's payload.

A core is like an "object" in a conventional language, but its attributes (arms) are functions on the core, not the core and an argument. A "method" on a core is an arm that produces a gate.

Examples

A trivial core:

> =foo =+  x=58
       |%
       ++  n  (add 42 x)
       ++  g  |=  b=@
              (add b n)
       --

> n.foo
100

> (g.foo 1)
101

|. "bardot"

Produce a trap (a core with one arm $).

Syntax

One argument, fixed.

Tall form
Wide form
Irregular form

| . a

| .(a)

None

AST

[%brdt p=hoon]

Expands to

|%  ++  $  a=hoon
--

Semantics

A |. expression produces a core with a single arm, $. The core isn't explicitly given a sample. a is a Hoon expression that defines the computation of the $ arm.

The payload of the core is the subject of the |. expression.

Discussion

A trap is generally used to defer a computation.

Examples

A trivial trap:

> =foo |.(42)

> $:foo
42

> (foo)
42

A more interesting trap:

> =foo =/  reps  10
       =/  step  0
       =/  outp  0
       |.
       ?:  =(step reps)
         outp
       $(outp (add outp 2), step +(step))

> (foo)
20

Note that we can use $() to recurse back into the trap, since it's a core with an $ arm.

$(...) expands to %=($ ...) ("centis").


|^ "barket"

Produce a core whose battery includes a $ arm and compute the latter.

Syntax

One fixed argument, then a variable number of +-family expressions.

|^  a=hoon
++  b=term  c=hoon
++  d=term  e=hoon
     ...
++  f=term  g=hoon
--

None

None

AST

[%brkt p=hoon q=(map term tome)]

Expands to

=>  |%
    ++  $  a=hoon
    ++  b=term  c=hoon
    ++  d=term  e=hoon
           ...
    ++  f=term  g=hoon
    --
$

Semantics

A |^ expression produces a multi-arm core whose battery includes a $ arm, which is evaluated immediately. a is a Hoon expression that defines the product of the $ arm. a is followed by a series of arm definitions for the rest of the core battery arms. There must be at least one arm other than the $ arm.

Discussion

The |^ rune is useful when you define a multi-arm core in your code and a particular arm in it is to be evaluated immediately.

Examples

A trivial example:

> |^
  (add n g)
  ++  n  42
  ++  g  58
  --
100

|- "barhep"

Produce a trap (a core with one arm $) and evaluate it.

Syntax

One argument, fixed.

Tall form
Wide form
Irregular form

|- a

|-(a)

None

AST

[%brhp p=hoon]

Expands to

=<($ |.(a=hoon))

Semantics

A |- expression produces a core with one arm named $ and immediately evaluates $. a is a Hoon expression that determines what $ evaluates to.

Discussion

The |- rune can be thought of as a 'recursion point' or a 'loop starting point'. Since |- makes a |. ("bardot", a core with one arm named $, we can recurse back into it with $().

$(...) expands to %=($ ...) ("centis").

Examples

A trivial computation doesn't recurse:

> |-(42)
42

The classic loop is a decrement:

> =foo =/  a  42
       =/  b  0
       |-
       ?:  =(a +(b))
         b
       $(b +(b))

> foo
41

|~ "barsig"

Produce an iron gate.

Syntax

Two arguments, fixed.

|~  a
b
|~(a b)

None

AST

[%brsg p=spec q=hoon]

Expands to

^|  |=(a b)

Semantics

A |~ expression produces an iron gate. a defines the sample, and b defines the output value of the gate.

Discussion

See this discussion of core variance models

Examples

> =>  ~  ^+(|~(a=@ *@) |=(a=* *@))
<1|usl {a/@ $~}>

|* "bartar"

Produce a wet gate (one-armed core with sample).

Syntax

Two arguments, fixed.

Tall form
Wide form
Irregular form

|* a b

|*(a b)

None

AST

[%brtr p=spec q=hoon]

Expands to

=|  a
|@
++  $
  b
--

Semantics

A |* expression produces a wet gate. a defines the gate's sample, and b is a Hoon expression that determines the output value of the gate.

Discussion

In a normal (dry) gate, your argument is converted into the sample type. In a generic (wet) gate, your argument type passes through the function, rather as if it were a macro (there is still only one copy of the code, however).

Genericity is a powerful and dangerous tool. Use wet gates only if you know what you're doing.

Just as with a gate, we can recurse back into a wet gate with $().

$(...) expands to %=($ ...) ("centis").

|* can be used to make wet gates that produce structures, but this usage is discouraged in favor of |$.

Examples

Wet and dry gates in a nutshell:

> =foo |=([a=* b=*] [b a])

> =bar |*([a=* b=*] [b a])

> (foo %cat %dog)
[6.778.724 7.627.107]

> (bar %cat %dog)
[%dog %cat]

The dry gate does not preserve the type of a and b; the wet gate does.


|= "bartis"

Produce a gate (a one-armed core with a sample).

Syntax

Two arguments, fixed.

|=  a
b
|=(a b)

None

AST

[%brts p=spec q=hoon]

Expands to

=+  ^~(*a=spec)
|%  ++  $  b=hoon
--

Definition

The product of a |= expression is a dry gate, i.e., a Hoon function.

p defines the gate sample type -- i.e., the input value type -- and usually includes a sample name assignment (e.g., a=@). q is an expression that determines the output value of the gate.

Discussion

Dry gates are used for the vast majority of ordinary functions in Hoon.

A gate is a core with one arm named $, so we can recurse back into it with $().

$(...) expands to %=($ ...) ("centis").

Examples

A trivial gate:

> =foo |=(a=@ +(a))

> (foo 20)
21

A slightly less trivial gate:

> =foo |=  [a=@ b=@]
       (add a b)

> (foo 30 400)
430

|@ "barpat"

Produce a 'wet' core [battery payload].

Syntax

Arguments: a variable number of +-family expressions.

|@
++  a=term  b=hoon
++  c=term  d=hoon
     ...
++  e=term  f=hoon
--

None

None

Note: The ++ rune may be replaced with any other rune in the + family.

AST

[%brpt p=(unit term) q=(map term tome)]

Semantics

A |@ expression produces a 'wet' core whose payload is the expression's subject. The various arms in the battery are each named (a, c, and e above) and defined explicitly with a Hoon expression (with b, d, and f above).

Discussion

The |@ rune is just like the |% rune except that instead of producing a 'dry' core, it produces a 'wet' one. This allows for type polymorphism of its arms, using 'genericity'. See Advanced types.


|? "barwut"

Produce a lead trap.

Syntax

One argument, fixed.

Tall form
Wide form
Irregular form

|? a

|?(a)

None

AST

[%brwt p=hoon]

Expands to

^?  |.  a

Semantics

A |? expression produces a lead trap (i.e., a lead core with one arm named $). a is a Hoon expression that defines what the $ arm does.

Discussion

See this discussion of the core variance model.

Examples

> =>  ~  ^+  |?(%a)  |.(%a)
<1?pqz $~>

> =>  ~  ^+  |?(%a)  |.(%b)
nest-fail
PreviousRunesNext$ buc · Structures

Last updated 1 day ago