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
  • mark conversion gates
  • Static
  • Dynamic
  • mark cores
  • Static
  • Dynamic
Edit on GitHub
  1. Urbit OS
  2. Kernel
  3. Clay
  4. Marks

Using Marks

In the last document, Writing Marks, we walked through writing mark files and touched on how Clay handles them. They needn't just be left to background vane processes though, you can also use them yourself in your code.

There are two kinds of cores that Clay can build for you: A mark conversion gate and a mark core. Each has two kinds: Statically typed and dynamically typed. Clay has a care for producing each of these:

  • %b - Build a dynamically typed mark core.

  • %c - Build a dynamically typed mark conversion gate.

  • %e - Build a statically typed mark core.

  • %f - Build a statically typed mark conversion gate.

You can either use these by %passing Clay a %warp task with the appropriate care, or else with a Clay scry. In the examples here we've used the latter.

mark conversion gates

mark conversion gates simply convert from one mark to another.

Static

A static mark conversion gate looks like $-(a b), where a is the type of the mark you're converting from, and b is type of the mark you're converting to. For example, a mark conversion gate from %txt to %mime would look like $-(wain mime). You'd simply feed it a wain and get a $mime in return.

Example

We get our %txt to %mime mark conversion gate with a %f scry like so:

> =txt-to-mime .^($-(wain mime) %cf /===/txt/mime)

Note we had to specify the type of the gate as $-(wain mime) in the scry - if the type returned by the scry doesn't match that specification it'll fail. This is where a statically typed mark conversion gate differs from the dynamically typed gate, which we'll discuss later.

Now that we have our conversion gate, we can just call it with a valid wain and we'll get our $mime in return:

> (txt-to-mime ~['foo'])
[p=/text/plain q=[p=3 q=7.303.014]]

Dynamic

A dynamically typed mark conversion gate is called a $tube:clay, and looks like:

+$  tube  $-(vase vase)

As you can see from the type definition, it takes and returns a vase rather than needing the types explicitly defined. Rather than failing on a type mismatch when the scry is performed, it'll instead fail when it's actually run and fed a vase of the wrong type. Apart from handling vases, it otherwise behaves the same as a statically typed mark conversion gate.

Example

We get our %txt to %mime $tube with a %c scry like so:

> =txt-mime-tube .^(tube:clay %cc /===/txt/mime)

And then we can again feed it the wain that a %txt mark wants, only this time it's wrapped in a vase:

> !<  mime  (txt-mime-tube !>(~['foo']))
[p=/text/plain q=[p=3 q=7.303.014]]

We then get our $mime back, but also in a vase.

mark cores

While a mark conversion gate is built from functions defined in +grab and +grow, a mark core gives you everything in +grad so you can create diffs, merge diffs, patch files, etc. An extra arm +vale is also included that lets you convert a noun to the type the %mark takes by running the +noun arm of +grab in the original mark file.

Static

A statically typed mark core is a (nave:clay a b) where a is the type of the mark and b is the type for diffs (which is the type of the mark specified in +form:grad). For example, a static mark core for a %txt mark looks like (nave:clay wain (urge:clay cord)).

+nave:clay looks like this in full:

++  nave
  |$  [typ dif]
  $_
  ^?
  |%
  ++  diff  |~([old=typ new=typ] *dif)
  ++  form  *mark
  ++  join  |~([a=dif b=dif] *(unit (unit dif)))
  ++  mash
    |~  [a=[ship desk dif] b=[ship desk dif]]
    *(unit dif)
  ++  pact  |~([typ dif] *typ)
  ++  vale  |~(noun *typ)
  --

In brief, the arms of the core do the following:

  • +form - mark for diffs.

  • +vale - Clam noun to the mark's type.

  • +diff - Create diff of two files.

  • +pact - Patch a file with a diff.

  • +join - Merge two diffs, returning ~ if there's a conflict.

  • +mash - Force merge of two diffs.

Examples

First we get the %txt mark core with a %e scry:

> =txt-nave .^((nave:clay wain (urge:clay cord)) %ce /===/txt)

Note we specified the mark type wain and diff type (urge:clay cord) in the nave returned by the scry.

We can see the mark for diffs with +form:

> form.txt-nave
%txt-diff

To clam a noun to the type of the mark (a wain in the case of a %txt mark), we can call +vale with a noun:

> (vale:txt-nave ~['foo' 'bar'])
<|foo bar|>

We can create a diff of two files with +diff:

> (diff:txt-nave ~['foo' 'bar' 'baz'] ~['foo' 'zoo' 'baz'])
~[[%.y p=1] [%.n p=<|bar|> q=<|zoo|>] [%.y p=1]]

Let's create some more diffs for experimentation:

> =diff-a (diff:txt-nave ~['foo' 'bar' 'baz'] ~['foo' 'zoo' 'baz'])
> =diff-b (diff:txt-nave ~['foo' 'bar' 'baz'] ~['zap' 'bar' 'baz'])
> =diff-c (diff:txt-nave ~['foo' 'bar' 'baz'] ~['foo' 'bla' 'baz'])

If we try merging diffs a and b with +join, we get a new merged diff back in a unit:

> (join:txt-nave diff-a diff-b)
[~ [~ ~[[%.n p=<|foo|> q=<|zap|>] [%.n p=<|bar|> q=<|zoo|>] [%.y p=1]]]]

If we try merging diffs a and c however, we get ~ because of a conflict:

> (join:txt-nave diff-a diff-c)
[~ ~]

If we run +mash on a and b we get the same diff as with +join (sans the unit):

> (mash:txt-nave [our %base diff-a] [our %blah diff-b])
[~ ~[[%.n p=<|foo|> q=<|zap|>] [%.n p=<|bar|> q=<|zoo|>] [%.y p=1]]]

If we +mash a and c, however, we get a diff with the conflict annotated rather than just ~:

> (mash:txt-nave [our %base diff-a] [our %blah diff-c])
[ ~
  ~[
    [%.y p=1]
    [ %.n
      p=<|bar|>
        q
      <|>>>>>>>>>>>> ~zod/base zoo ++++++++++++ bar ------------ bla <<<<<<<<<<<< ~zod/blah|>
    ]
    [%.y p=1]
  ]
]

Note that the %txt mark annotates conflicts, but there are no specific rules around how the +mash arm should force-merge conflicting diffs apart from that it must return a valid diff, however the mark specified in +form defines that.

Finally, we can patch our wain with diff a and get a new, modified wain:

> (pact:txt-nave ~['foo' 'bar' 'baz'] diff-a)
<|foo zoo baz|>

Dynamic

A dynamically typed mark core is a $dais:clay, which looks like:

+$  dais
  $_  ^|
  |_  sam=vase
  ++  diff  |~(new=_sam *vase)
  ++  form  *mark
  ++  join  |~([a=vase b=vase] *(unit (unit vase)))
  ++  mash
    |~  [a=[ship desk diff=vase] b=[ship desk diff=vase]]
    *(unit vase)
  ++  pact  |~(diff=vase sam)
  ++  vale  |~(noun sam)
  --

It has the same arms as the statically typed mark core, the difference is that it takes and returns vases rather than the data directly. Additionally, it's a door rather than an ordinary core, and takes the type of the mark wrapped in a vase as its argument.

Examples

We can get a %txt mark dais with a %b scry:

> =txt-dais .^(dais:clay %cb /===/txt)

Its +form arm functions the same as a static core:

> form.txt-dais
%txt-diff

So does +vale except it returns a vase:

> !<  wain  (vale:txt-dais ~['foo' 'bar'])
<|foo bar|>

All the other arms also deal in vases. Because it's a door, the +pact and +diff arms take the original file in a vase as the door sample rather than being given directly to the arm. Calling +diff arm, for example, works like so:

> !<  (urge:clay cord)  (~(diff txt-dais !>(~['foo' 'bar'])) !>(~['foo' 'baz']))
~[[%.y p=1] [%.n p=<|bar|> q=<|baz|>]]
PreviousMark ExamplesNextWriting Marks

Last updated 1 day ago