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
  • Overview
  • $| "bucbar"
  • $_ "buccab"
  • $% "buccen"
  • $: "buccol"
  • $< "bucgal"
  • $> "bucgar"
  • $- "buchep"
  • $^ "bucket"
  • $+ "buclus"
  • $& "bucpam"
  • $~ "bucsig"
  • $@ "bucpat"
  • $= "buctis"
  • $? "bucwut"
Edit on GitHub
  1. Hoon
  2. Runes

$ buc · Structures

The $ family of runes is used for defining custom types. Strictly speaking, these runes are used to produce specs, which we call 'structures'.

Overview

Structures are abstract syntax trees for types (see the documentation on basic and advanced types for the precise definition of type). Structures are compile-time values of type which at runtime may be used to produce a 'mold'.

A mold is a function from nouns to nouns used to validate values of the type to which the structure defines. A mold can do two things at runtime. First, it may 'clam' a noun, which validates the shape of the noun to be one that fits the abstract syntax tree given by the spec that produced the mold. Failing this validation results in a crash. Secondly, a mold may also be used to produce an example value of the type to which is corresponds, called the 'bunt value'. The bunt value is used as a placeholder for sample values that may be passed to a gate that accepts the corresponding type.

A correct mold is a normalizer: an idempotent function across all nouns. If the sample of a gate has type %noun, and its body obeys the constraint that for any x, =((mold x) (mold (mold x))), it's a normalizer and can be used as a mold. Hoon is not dependently typed and so can't check idempotence statically, so we can't actually tell if a mold matches this definition perfectly. This is not actually a problem.

In any case, since molds are just functions, we can use functional programming to assemble interesting molds. For instance, (map foo bar) is a table from mold foo to mold bar. map is not a mold; it's a function that makes a mold. Molds and mold builders are generally described together.

specs contain more information and draw finer distinctions than types, which is to say that a given type may have more than one valid spec defining it, and thus downconversion from spec to type is lossy. Thus structure validation (done with $|, which is a more restrictive validation than that performed by molds, is a rare use case. Except for direct raw input, it's generally a faux pas to validate structure at runtime -- or even in userspace. Nonetheless they are sometimes utilized for types that will be more performant if they satisfy some validating gate.


$| "bucbar"

Structure that satisfies a validator.

Syntax

Two arguments, fixed.

$|  p
q
$|(p q)

None

AST

[%bcbr p=spec q=hoon]

Discussion

$| is used for validation of values at a finer level than that of types. Recall that a given value of type can be equivalently defined by more than one spec. For performance reasons, it may be beneficial to restrict oneself to values of a given type that adhere to an abstract syntax tree specified by some subset of those specs that may be used to define a given type.

$| takes two arguments: a structure a and a gate b that produces a flag that is used to validate values produced by the mold generated by a at runtime. $|(a b) is a gate that takes in a noun x and first pins the product of clamming a with x, call this foo. Then it calls b on foo. It asserts that the product of (b foo) is &, and then produces foo. This is equivalent to the following (which is not how $| is actually defined but has the same behavior):

|=  x=*
=/  foo  ;;(a x)
?>  (b foo)
foo

For example, the elements of a set are treated as being unordered, but the values will necessarily possess an order by where they are in the memory. Thus if every set is stored using the same order scheme then faster algorithms involving sets may be written. Furthermore, if you just place elements in the set randomly, it may be mistreated by algorithms already in place that are expecting a certain order. This is not the same thing as casting - it is forcing a type to have a more specific set of values than its mold would suggest. This rune should rarely be used, but it is extremely important when it is.

Examples

> =foo $|  (list @)
       |=(a=(list) (lth (lent a) 4))

This creates a structure foo whose values are lists with length less than 4.

> (foo ~[1 2 3])
~[1 2 3]

> (foo ~[1 2 3 4])
ford: %ride failed to execute:

The definition of +set in hoon.hoon is the following:

++  set
  |$  [item]
  $|  (tree item)
  |=(a=(tree) ?:(=(~ a) & ~(apt in a)))

Here |$ is used to define a mold builder that takes in a mold (given the face item) and creates a structure consisting of a tree of items with $| that is validated with the gate |=(a=(tree) ?:(=(~ a) & ~(apt in a))). in is a door in hoon.hoon with functions for handling sets, and apt is an arm in that door that checks that the values in the tree are arranged in the particular way that sets are arranged in Hoon, namely 'ascending +mug hash order'.


$_ "buccab"

Structure that normalizes to an example.

Syntax

One argument, fixed.

Tall form
Wide form
Irregular form

$_ p

$_(p)

_p

AST

[%bccb p=hoon]

Expands to

|=(* p)

Discussion

$_ discards the sample it's supposedly normalizing and produces its example instead.

Examples

> =foo $_([%foobaz %moobaz])

> (foo %foo %baz)
[%foobaz %moobaz]

> `foo`[%foobaz %moobaz]
[%foobaz %moobaz]

> $:foo
[%foobaz %moobaz]

$% "buccen"

Structure which recognizes a union tagged by head atom.

Syntax

A variable number of arguments.

$%  [%p1 ...]
    [%p2 ...]
    [%p3 ...]
    [%pn ...]
==
$%([%p1 ...] [%p2 ...] [%p3 ...] [%pn ...])

None

Each item may be an atom or (more commonly) a cell. The atom or head of the cell must be a constant (%foo, %1, %.y, etc).

AST

[%bccn p=(list spec)]

Defaults to

The default of the last item i in p. Crashes if p is empty.

Discussion

A $% is a tagged union, a common data model.

Make sure the last item in your $% terminates, or the default will be an infinite loop! Alteratively, you can use $~ to define a custom type default value.

Examples

> =foo $%([%foo p=@ud q=@ud] [%baz p=@ud])

> (foo [%foo 4 2])
[%foo p=4 q=2]

> (foo [%baz 37])
[%baz p=37]

> $:foo
[%baz p=0]

$: "buccol"

Form a cell type.

Syntax

A variable number of arguments.

$:  p1
    p2
    p3
    pn
==
$:(p1 p2 p3 pn)
,[p1 p2 p3 pn]
  [p1 p2 p3 pn]

AST

[%bccl p=(list spec)]

Normalizes to

The tuple the length of p, normalizing each item.

Defaults to

The tuple the length of p.

Examples

> =foo $:(p=@ud q=@tas)

> (foo 33 %foo)
[p=33 q=%foo]

> `foo`[33 %foo]
[p=33 q=%foo]

> $:foo
[p=0 q=%$]

$< "bucgal"

Filters a pre-existing mold to obtain a mold that excludes a particular structure.

Syntax

Two arguments, fixed.

$<  p
q
$<(p q)

None

AST

[%bcgl p=spec q=spec]

Discussion

This can be used to obtain type(s) from a list of types q that do not satisfy a requirement given by p.

Examples

> =foo $%([%bar p=@ud q=@ud] [%baz p=@ud])

> =m $<(%bar foo)

> (m [%bar 2 4])
ford: %ride failed to execute:

> (m [%baz 2])
[%baz p=2]

> ;;($<(%foo [@tas *]) [%foo 1])
ford: %ride failed to execute:

> ;;($<(%foo [@tas *]) [%bar 1])
[%bar 1]

$> "bucgar"

Filters a mold to obtain a new mold matching a particular structure.

Syntax

Two arguments, fixed.

$>  p
q
$>(p q)

None

AST

[%bcgr p=spec q=spec]

Discussion

This can be used to obtain type(s) from a list of types q that satisfy a requirement given by p.

Examples

Examples with $%:

> =foo $%([%bar p=@ud q=@ud] [%baz p=@ud])

> =m $>(%bar foo)

> (m [%bar 2 4])
[%bar p=2 q=4]

> (m [%baz 2])
ford: %ride failed to execute:

Examples with ;;:

> ;;([@tas *] [%foo 1])
[%foo 1]

> ;;([@tas *] [%bar 1])
[%bar 1]

> ;;($>(%foo [@tas *]) [%foo 1])
[%foo 1]

> ;;($>(%foo [@tas *]) [%bar 1])
ford: %ride failed to execute:

$- "buchep"

Structure that normalizes to an example gate.

AST

[%bchp p=spec q=spec]

Expands to

$_  ^|
|=(p $:q)

Syntax

Two arguments, fixed.

$-  p
q
$-(p q)

None

p is the type the gate takes and q is the type the gate produces.

Discussion

Since a $- reduces to a $_, it is not useful for normalizing, just for typechecking. In particular, the existence of $-s does not let us send gates or other cores over the network!

Examples

> =foo $-(%foo %baz)

> ($:foo %foo)
%baz

$^ "bucket"

Structure which normalizes a union tagged by head depth (cell).

Syntax

Two arguments, fixed.

$^  p
q
$^(p q)

None

AST

[%bckt p=spec q=spec]

Normalizes to

Default, if the sample is an atom; p, if the head of the sample is an atom; q otherwise.

Defaults to

The default of p.

Examples

> =a $%([%foo p=@ud q=@ud] [%baz p=@ud])

> =b $^([a a] a)

> (b [[%baz 33] [%foo 19 22]])
[[%baz p=33] [%foo p=19 q=22]]

> (b [%foo 19 22])
[%foo p=19 q=22]

> $:b
[%baz p=0]

$+ "buclus"

Specify a shorthand type name for use in prettyprinting.

Syntax

Two arguments, fixed.

$+  p
q
$+(p q)

None

AST

[%bcls p=stud q=spec]

Examples

> =/  my-type  $+(my-alias [@ @])

> -:!>(*my-type)
#t/#my-alias

$& "bucpam"

Repair a value of a tagged union type.

Syntax

Two arguments, fixed.

$&  p
q
$&(p q)

None

$&(combined-mold=spec normalizing-gate=hoon)

Here combined-mold is a tagged union type (typically made with $%) and normalizing-gate is a gate which accepts values of combined-mold and normalizes them to be of one particular type in combined-mold.

AST

[%bcpm p=spec q=hoon]

Normalizes to

The product of the normalizing gate and sample.

Defaults to

The default of the last type listed in p, normalized with the normalizing gate.

Discussion

This rune is used to "upgrade" or "repair" values of a structure, typically from an old version to a new version. For example, this may happen when migrating state after updating an app.

Examples

+$  old  [%0 @]
+$  new  [%1 ^]
+$  combined  $%(old new)
+$  adapting  $&(combined |=(?-(-.a %0 [%1 1 +.a], %1 a)))

Here adapting is a structure that bunts to [%1 ^] but also normalizes from [%0 @] if called on such a noun.


$~ "bucsig"

Define a custom type default value.

Syntax

Two arguments, fixed.

$~  p
q
$~(p q)

None

p defines the default value, and q defines everything else about the structure.

AST

[%bcsg p=hoon q=spec]

Product

Creates a structure (custom type) just like q, except its default value is p.

Defaults to

The product of p.

Discussion

You should make sure that the product type of p nests under q. You can check the default value of some structure (custom type) r with *r. (See the ^* rune.)

Do not confuse the $~ rune with the constant type for null, $~. (The latter uses older Hoon syntax that is still accepted. Preferably it would be %~.)

Examples

First, let's define a type without using $~:

> =b $@(@tas $%([%two *] [%three *]))

> `b`%hello
%hello

> `b`[%two %hello]
[%two 478.560.413.032]

> *b

%$

> *@tas
%$

Using $~:

> =c $~(%default-value $@(@tas $%([%two *] [%three *])))

> `c`%hello
%hello

> `c`[%two %hello]
[%two 478.560.413.032]

> *c
%default-value

$@ "bucpat"

Structure which normalizes a union tagged by head depth (atom).

Syntax

Two arguments, fixed.

$@  p
q
$@(p q)

None

AST

[%bcpt p=spec q=spec]

Normalizes to

p, if the sample is an atom; q, if the sample is a cell.

Defaults to

The default of p.

Produces

A structure which applies p if its sample is an atom, q if its sample is a cell.

Examples

> =a $@(%foo $:(p=%baz q=@ud))

> (a %foo)
%foo

> `a`[%baz 99]
[p=%baz q=99]

> $:a
%foo

$= "buctis"

Structure which wraps a face around another structure.

Syntax

Two arguments, fixed.

$=  p
q
$=(p q)
  p=q

AST

[%bcts p=skin q=spec]

Expands to

|=  *
^=(p %-(q +6))

Discussion

Note that the Hoon compiler is at least slightly clever about compiling structures, and almost never has to actually put in a gate layer (as seen in the expansion above) to apply a $=.

Examples

> =a $=(p %foo)

> (a %foo)
p=%foo

> (a %baz)
ford: %ride failed to execute:

$? "bucwut"

Form a type from a union of other types.

Syntax

Variable number of arguments.

$?  p1
    p2
    p3
    pn
==
$?(p1 p2 p3 pn)
  ?(p1 p2 p3 pn)

AST

[%bcwt p=(list spec)]

Normalizes to

The last item in p which normalizes the sample to itself.

Void, if p is empty.

Defaults to

The last item in p.

Discussion

For a union of atoms, a $? is fine. For more complex nouns, always try to use a $%, $@ or $^, at least if you expect your structure to be used as a normalizer.

Examples

> =a ?(%foo %baz %baz)

> (a %baz)
%baz

> (a [37 45])
ford: %ride failed to execute:

> $:a
%baz
Previous| bar · CoresNext% cen · Calls

Last updated 1 day ago