Urbit Developers
  • Lightning Tutorials

    • Introduction
    • Build a Groups App
    • Build a Chat App
    • Build a Voting App
    • Core Curriculum

      • Hoon School

        • Introduction
        • 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

          • Introduction
          • 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)

            • Introduction
            • 1. Types
            • 2. Agent
            • 3. JSON
            • 4. Marks
            • 5. Eyre
            • 6. React app setup
            • 7. React app logic
            • 8. Desk and glob
            • 9. Summary
          • Environment Setup
          • Additional Guides

            • Threads

              • Fundamentals
              • Bind
              • Input
              • Output
              • Summary
              • Hoon Workbook

                • Rhonda Numbers
                • Roman Numerals
                • Solitaire Cipher
              • Writing Aqua Tests
              • CLI Apps
              • Serving a Browser Game
              • Using the HTTP API
              • Working with JSON
              • Parsing
              • Sail: HTML in Hoon
              • Distributing Software
              • Working with Strings
              • Writing Unit Tests
              Urbit Developers
              • Lightning Tutorials

                • Introduction
                • Build a Groups App
                • Build a Chat App
                • Build a Voting App
                • Core Curriculum

                  • Hoon School

                    • Introduction
                    • 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

                      • Introduction
                      • 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)

                        • Introduction
                        • 1. Types
                        • 2. Agent
                        • 3. JSON
                        • 4. Marks
                        • 5. Eyre
                        • 6. React app setup
                        • 7. React app logic
                        • 8. Desk and glob
                        • 9. Summary
                      • Environment Setup
                      • Additional Guides

                        • Threads

                          • Fundamentals
                          • Bind
                          • Input
                          • Output
                          • Summary
                          • Hoon Workbook

                            • Rhonda Numbers
                            • Roman Numerals
                            • Solitaire Cipher
                          • Writing Aqua Tests
                          • CLI Apps
                          • Serving a Browser Game
                          • Using the HTTP API
                          • Working with JSON
                          • Parsing
                          • Sail: HTML in Hoon
                          • Distributing Software
                          • Working with Strings
                          • Writing Unit Tests
                          Guides/Additional Guides/Threads

                          Output

                          A strand produces a [(list card) <response>]. The first part is a list of cards to be sent off immediately, and <response> is one of:

                          • [%wait ~]
                          • [%skip ~]
                          • [%cont self=(strand-form-raw a)]
                          • [%fail err=(pair term tang)]
                          • [%done value=a]

                          So, for example, if you feed 2 2 into the following function:

                          |= [a=@ud b=@ud]
                          =/ m (strand ,vase)
                          ^- form:m
                          =/ res !>(`@ud`(add a b))
                          (pure:m res)

                          The resulting strand won't just produce [#t/@ud q=4], but rather [~ %done [#t/@ud q=4]].

                          Note: that spider doesn't actually return the codes themselves to thread subscribers, they're only used internally to manage the flow of the thread.

                          Since a strand is a function from the previously discussed strand-input to the output discussed here, you can compose a valid strand like:

                          |= strand-input:strand
                          [~ %done 'foo']

                          So this is a valid thread:

                          /- spider
                          =, strand=strand:spider
                          ^- thread:spider
                          |= arg=vase
                          =/ m (strand ,vase)
                          ^- form:m
                          |= strand-input:strand
                          [~ %done arg]

                          As is this:

                          /- spider
                          =, strand=strand:spider
                          |%
                          ++ my-function
                          =/ m (strand ,@t)
                          ^- form:m
                          |= strand-input:strand
                          [~ %done 'foo']
                          --
                          ^- thread:spider
                          |= arg=vase
                          =/ m (strand ,vase)
                          ^- form:m
                          ;< msg=@t bind:m my-function
                          (pure:m !>(msg))

                          As is this:

                          /- spider
                          =, strand=strand:spider
                          ^- thread:spider
                          |= arg=vase
                          =/ m (strand ,vase)
                          ^- form:m
                          |= strand-input:strand
                          =/ umsg !< (unit @tas) arg
                          ?~ umsg
                          [~ %fail %no-arg ~]
                          =/ msg=@tas u.umsg
                          ?. =(msg %foo)
                          [~ %fail %not-foo ~]
                          [~ %done arg]

                          Which works like:

                          > -mythread
                          thread failed: %no-arg
                          > -mythread %bar
                          thread failed: %not-foo
                          > -mythread %foo
                          [~ %foo]

                          Now let's look at the meaning of each of the response codes.

                          wait

                          Wait tells spider not to move on from the current strand, and to wait for some new input. For example, sleep:strandio will return a [%wait ~] along with a card to start a behn timer. Spider passes the card to behn, and when behn sends a wake back to spider, the new input will be given back to sleep as a %sign. Sleep will then issue [~ %done ~] and (assuming it's in a bind) bind will proceed to the next strand.

                          skip

                          Spider will normally treat a %skip the same as a %wait and just wait for some new input. When used inside a main-loop:strandio, however, it will instead tell main-loop to skip this function and try the next one with the same input. This is very useful when you want to call different functions depending on the mark of a poke or some other condition.

                          cont

                          Cont means continue computation. When a %cont is issued, the issuing gate will be called again with the new value provided. Therefore %cont essentially creates a loop.

                          fail

                          Fail says to end the thread here and don't call any subsequent strands. It includes an error message and optional traceback. When spider gets a %fail it will send a fact with mark %thread-fail containing the error and traceback to its subscribers, and then end the thread.

                          done

                          Done means the computation was completed successfully and includes the result. When spider recieves a %done it will send the result it contains in a fact with a mark of %thread-done to subscribers and end the thread. When bind receives a %done it will extract the result and call the next gate with it.

                          <-

                          Input

                          Summary

                          ->

                          Edit this page on GitHub

                          Last modified October 31, 2022