mirror of
https://github.com/urbit/developers.urbit.org.git
synced 2024-09-11 13:55:59 +03:00
Add numbers to titles.
This commit is contained in:
parent
cd2a1b1533
commit
ee6445506d
@ -1,12 +1,10 @@
|
||||
+++
|
||||
title = "Introduction to Hoon"
|
||||
title = "1. Introduction to Hoon"
|
||||
weight = 10
|
||||
nodes = [100, 103]
|
||||
objectives = ["Explain what an Urbit ship is.", "Distinguish a fakeship from a liveship.", "Pronounce ASCII characters per standard Hoon developer practice."]
|
||||
+++
|
||||
|
||||
# Introduction to Hoon
|
||||
|
||||
Hoon School is designed to teach you Hoon without assuming you have an extensive programming background. You should be able to following most of it even if you have no programming experience at all yet, though of course experience helps. We strongly encourage you to try out all the examples of each lesson. Hoon School is meant for the beginner, but it's not meant to be skimmed. Each lesson consists of:
|
||||
|
||||
- **Explanations**, which are prose-heavy commentary on the Hoon fundamentals.
|
||||
|
@ -1,12 +1,10 @@
|
||||
+++
|
||||
title = "Hoon Syntax"
|
||||
title = "2. Hoon Syntax"
|
||||
weight = 10
|
||||
nodes = [110, 113]
|
||||
objectives = ["Distinguish nouns, cells, and atoms.", "Apply auras to transform an atom.", "Identify common Hoon molds, such as cells, lists, and tapes.", "Pin a face to the subject.", "Make a decision at a branch point.", "Distinguish loobean from boolean operations.", "Slam a gate (call a function)."]
|
||||
+++
|
||||
|
||||
# Hoon Syntax
|
||||
|
||||
_This module will discuss the fundamental data concepts of Hoon and how programs effect control flow._
|
||||
|
||||
The study of Hoon can be divided into two parts: syntax and semantics.
|
||||
|
@ -1,12 +1,10 @@
|
||||
+++
|
||||
title = "Azimuth (Urbit ID)"
|
||||
title = "3. Azimuth (Urbit ID)"
|
||||
weight = 10
|
||||
nodes = [102, 112]
|
||||
objectives = ["Understand the role of the public-key infrastructure in Urbit.", "Describe the high-level architecture of the Urbit ID address space and distinguish types of points.", "Interpret and apply the Azimuth point naming scheme.", "Identify point features such as activity.", "List at least two services/roles provided by a galaxy for the network.", "List at least two services provided by a star for its planets.", "Use Hoon to map the Azimuth address space domains and boundaries.", "Identify points, sponsors, neighbors, etc. from `@p` identifiers and simple operations."]
|
||||
+++
|
||||
|
||||
# Azimuth (Urbit ID)
|
||||
|
||||
_This module introduces how Urbit ID is structured and provides practice in converting and working with `@p` identity points. It may be considered optional and skipped if you are speedrunning Hoon School._
|
||||
|
||||
## A Public-Key Infrastructure
|
||||
|
@ -1,12 +1,10 @@
|
||||
+++
|
||||
title = "Gates (Functions)"
|
||||
title = "4. Gates (Functions)"
|
||||
weight = 10
|
||||
nodes = [111, 115, 120]
|
||||
objectives = ["Use the `+ls` generator to show a directory's contents.", "`|mount` and `|commit` a desk.", "Identify current known irregular syntax.", "Convert between regular and irregular forms of runes to date.", "Employ a gate to defer a computation.", "Produce a gate as a generator.", "Annotate Hoon code with comments.", "Produce a generator to convert a value between auras."]
|
||||
+++
|
||||
|
||||
# Gates (Functions)
|
||||
|
||||
_This module will teach you how to produce deferred computations for later use, like functions in other languages._
|
||||
|
||||
## A Spoonful of Sugar
|
||||
|
@ -1,12 +1,10 @@
|
||||
+++
|
||||
title = "Molds (Types)"
|
||||
title = "5. Molds (Types)"
|
||||
weight = 10
|
||||
nodes = [125]
|
||||
objectives = ["Identify a mold in the hierarchy of Urbit types (nouns, molds, marks).", "Understand how type inference and type checking takes place.", "Bunt a mold.", "Produce a type union.", "Produce a named tuple.", "Identify type using `!>`."]
|
||||
+++
|
||||
|
||||
# Molds (Types)
|
||||
|
||||
_This module will introduce the Hoon type system and illustrate how type checking and type inference work._
|
||||
|
||||
## The Hoon Type System
|
||||
|
@ -1,12 +1,10 @@
|
||||
+++
|
||||
title = "Cores"
|
||||
title = "6. Cores"
|
||||
weight = 10
|
||||
nodes = [130, 133]
|
||||
objectives = ["Employ a trap to produce a reentrant block of code.", "Produce a recursive gate.", "Distinguish head and tail recursion.", "Consider Hoon structures as cores.", "Identify the special role of the `$` buc arm in many cores.", "Order neighboring cores within the subject for addressibility.", "Produce a type arm."]
|
||||
+++
|
||||
|
||||
# Cores
|
||||
|
||||
_This module will introduce the key Hoon data structure known as the **core**, as well as ramifications._
|
||||
|
||||
The Hoon subject is a noun. One way to look at this noun is to denote each fragment of is as either a computation or data. By strictly separating these two kinds of things, we derive the data structure known within Hoon as a _core_.
|
||||
|
@ -1,12 +1,10 @@
|
||||
+++
|
||||
title = "Trees, Addressing, and Lists"
|
||||
title = "7. Trees and Addressing"
|
||||
weight = 10
|
||||
nodes = [135, 140, 156]
|
||||
objectives = ["Address nodes in a tree using numeric notation.", "Address nodes in a tree using lark notation.", "Address data in a tree using faces.", "Distinguish `.` and `:` notation.", "Diagram Hoon structures such as gates into the corresponding abstract syntax tree.", "Use lists to organize data.", "Convert between kinds of lists (e.g. tapes).", "Diagram lists as binary trees.", "Operate on list elements using `snag`, `find`, `weld`, etc.", "Explain how Hoon manages the subject and wing search paths.", "Explain how to skip to particular matches in a wing search path through the subject.", "Identify common Hoon patterns: batteries, and doors, arms, wings, and legs."]
|
||||
+++
|
||||
|
||||
# Trees, Addressing, and Lists
|
||||
|
||||
_Every noun in Urbit is an atom or a cell. This module will elaborate how we can use this fact to locate data and evaluate code in a given expression. It will also discuss the important `list` mold builder and a number of standard library operations._
|
||||
|
||||
## Trees
|
||||
|
@ -1,12 +1,10 @@
|
||||
+++
|
||||
title = "Libraries"
|
||||
title = "8. Libraries"
|
||||
weight = 10
|
||||
nodes = [145, 153, 175]
|
||||
objectives = ["Import a library using `/+` faslus.", "Create a new library in `/lib`.", "Identify the role of a desk in the Clay filesystem.", "Identify the components of a beak.", "Identify filesystem locations (including desks).", "Identify the components of a path.", "Build code samples with `-build-file` thread.", "Discuss Ford import runes."]
|
||||
+++
|
||||
|
||||
# Libraries
|
||||
|
||||
_Libraries allow you to import and share processing code. This module will discuss how libraries can be produced, imported, and used._
|
||||
|
||||
## Importing a Library
|
||||
|
@ -1,12 +1,10 @@
|
||||
+++
|
||||
title = "Testing Code"
|
||||
title = "9. Testing Code"
|
||||
weight = 10
|
||||
nodes = [170, 190]
|
||||
objectives = ["Run existing unit tests.", "Produce a unit test.", "Employ a debugging strategy to identify and correct errors in Hoon code."]
|
||||
+++
|
||||
|
||||
# Testing Code
|
||||
|
||||
_This module will discuss how we can have confidence that a program does what it claims to do, using unit testing and debugging strategies._
|
||||
|
||||
> Code courageously.
|
||||
|
@ -1,12 +1,10 @@
|
||||
+++
|
||||
title = "Text Processing I"
|
||||
title = "10. Text Processing I"
|
||||
weight = 10
|
||||
nodes = [160, 163]
|
||||
objectives = ["Review Unicode text structure.", "Distinguish cords and tapes and their characteristics.", "Transform and manipulate text using text conversion arms.", "Interpolate text.", "Employ sigpam logging levels.", "Create a `%say` generator.", "Identify how Dojo sees and interprets a generator as a cell with a head tag.", "Identify the elements of a `sample` for a `%say` generator.", "Produce a `%say` generator with optional arguments."]
|
||||
+++
|
||||
|
||||
# Text Processing I
|
||||
|
||||
_This module will discuss how text is represented in Hoon, discuss tools for producing and manipulating text, and introduce the `%say` generator, a new generator type. We don't deal with formatted text (`tank`s) or parsers here, deferring that discussion. Formatted text and text parsing are covered [in a later module](./P-stdlib-io.md)._
|
||||
|
||||
## Text in Hoon
|
||||
|
@ -1,12 +1,10 @@
|
||||
+++
|
||||
title = "Cores and Doors"
|
||||
title = "11. Cores and Doors"
|
||||
weight = 10
|
||||
nodes = [150, 155]
|
||||
objectives = ["Identify the structure of a door and relate it to a core.", "Pull an arm in a door.", "Build cores for later use and with custom samples.", "Identify the `$` buc arm in several structures and its role."]
|
||||
+++
|
||||
|
||||
# Cores and Doors
|
||||
|
||||
_Hoon is statically typed, which means (among other things) that auras are subject to strict nesting rules, molds are crash-only, and the whole thing is rather cantankerous about matching types. However, since gate-building arms are possible, Hoon developers frequently employ them as templates to build type-appropriate cores, including gates. This module will start by introducing the concept of gate-building gates; then it will expand our notion of cores to include doors; finally it will introduce a common door, the `++map`, to illustrate how doors work._
|
||||
|
||||
## Gate-Building Gates
|
||||
|
@ -1,12 +1,10 @@
|
||||
+++
|
||||
title = "Data Structures"
|
||||
title = "12. Data Structures"
|
||||
weight = 10
|
||||
nodes = [183]
|
||||
objectives = ["Identify units, sets, maps, and compound structures like jars and jugs.", "Explain why units and vases are necessary.", "Use helper arms and syntax: `` ` ``, `biff`, `some`, etc."]
|
||||
+++
|
||||
|
||||
# Data Structures
|
||||
|
||||
_This module will introduce you to several useful data structures built on the door, then discuss how the compiler handles types and the sample._
|
||||
|
||||
|
||||
|
@ -1,12 +1,10 @@
|
||||
+++
|
||||
title = "Type Checking"
|
||||
title = "13. Type Checking"
|
||||
weight = 10
|
||||
nodes = [183]
|
||||
objectives = ["Use assertions to enforce type constraints."]
|
||||
+++
|
||||
|
||||
# Type Checking
|
||||
|
||||
_In this module we'll cover how the Hoon compiler infers type, as well as various cases in which a type check is performed._
|
||||
|
||||
|
||||
|
@ -1,12 +1,10 @@
|
||||
+++
|
||||
title = "Conditional Logic"
|
||||
title = "14. Conditional Logic"
|
||||
weight = 10
|
||||
nodes = [184]
|
||||
objectives = ["Produce loobean expressions.", "Reorder conditional arms.", "Switch against a union with or without default."]
|
||||
+++
|
||||
|
||||
# Conditional Logic
|
||||
|
||||
_Although you've been using various of the `?` wut runes for a while now, let's wrap up some loose ends. This module will cover the nature of loobean logic and the rest of the `?` wut runes._
|
||||
|
||||
|
||||
|
@ -1,12 +1,10 @@
|
||||
+++
|
||||
title = "Subject-Oriented Programming"
|
||||
title = "15. Subject-Oriented Programming"
|
||||
weight = 10
|
||||
nodes = [165, 180]
|
||||
objectives = ["Review subject-oriented programming as a design paradigm.", "Discuss stateful v. stateless applications and path dependence.", "Enumerate Hoon's tools for dealing with state: `=.` tisdot, `=^` tisket, `;<` micgal, `;~` micsig.", "Defer a computation."]
|
||||
+++
|
||||
|
||||
# Subject-Oriented Programming
|
||||
|
||||
_This module discusses how Urbit's subject-oriented programming paradigm structures how cores and values are used and maintain state, as well as how deferred computations and remote value lookups (“scrying”) are handled. This module does not cover core genericity and variance, which will be explained in [a later module](./R-metals.md)._
|
||||
|
||||
|
||||
|
@ -1,12 +1,10 @@
|
||||
+++
|
||||
title = "Text Processing II"
|
||||
title = "16. Text Processing II"
|
||||
weight = 10
|
||||
nodes = [185]
|
||||
objectives = ["Identify tanks, tangs, wains, walls, and similar formatted printing data structures.", "Interpret logging message structures (`%leaf`, `$rose`, `$palm`).", "Interpolate to tanks with `><` syntax.", "Produce useful error annotations using `~|` sigbar."]
|
||||
+++
|
||||
|
||||
# Text Processing II
|
||||
|
||||
_This module will elaborate on text representation in Hoon, including formatted text and `%ask` generators. It may be considered optional and skipped if you are speedrunning Hoon School._
|
||||
|
||||
|
||||
|
@ -1,12 +1,10 @@
|
||||
+++
|
||||
title = "Functional Programming"
|
||||
title = "17. Functional Programming"
|
||||
weight = 10
|
||||
nodes = [233, 283, 383]
|
||||
objectives = ["Reel, roll, turn a list.", "Curry, cork functions.", "Change arity of a gate.", "Tokenize text simply using `find` and `trim`.", "Identify elements of parsing: `nail`, `rule`, etc.", "Use `++scan` to parse `tape` into atoms.", "Construct new rules and parse arbitrary text fields."]
|
||||
+++
|
||||
|
||||
# Functional Programming
|
||||
|
||||
_This module will discuss some gates-that-work-on-gates and other assorted operators that are commonly recognized as functional programming tools. It will also cover text parsing._
|
||||
|
||||
Given a gate, you can manipulate it to accept a different number of values than its sample formally requires, or otherwise modify its behavior. These techniques mirror some of the common tasks used in other [functional programming languages](https://en.wikipedia.org/wiki/Functional_programming) like Haskell, Clojure, and OCaml.
|
||||
|
@ -1,12 +1,10 @@
|
||||
+++
|
||||
title = "Generic and Variant Cores"
|
||||
title = "18. Generic and Variant Cores"
|
||||
weight = 10
|
||||
nodes = [288, 299]
|
||||
objectives = ["Distinguish dry and wet cores.", "Describe use cases for wet gates (using genericity).", "Enumerate and distinguish use cases for dry cores (using variance):", "- Covariant (`%zinc`)", "- Contravariant (`%iron`)", "- Bivariant (`%lead`)", "- Invariant (`%gold`)"]
|
||||
+++
|
||||
|
||||
# Generic and Variant Cores
|
||||
|
||||
_This module introduces how cores can be extended for different behavioral patterns. It may be considered optional and skipped if you are speedrunning Hoon School._
|
||||
|
||||
Cores can expose and operate with many different assumptions about their inputs and structure. `[battery payload]` describes the top-level structure of a core, but within that we already know other requirements can be enforced, like `[battery [sample context]]` for a gate, or no `sample` for a trap. Cores can also expose and operate on their input values with different relationships. This lesson is concerned with examining [_genericity_](https://en.wikipedia.org/wiki/Generic_programming) including certain kinds of [parametric polymorphism](https://en.wikipedia.org/wiki/Parametric_polymorphism), which allows flexibility in type, and [_variance_](https://en.wikipedia.org/wiki/Covariance_and_contravariance_%28computer_science%29), which allows cores to use different sets of rules as they evaluate.
|
||||
|
@ -1,12 +1,10 @@
|
||||
+++
|
||||
title = "Mathematics"
|
||||
title = "19. Mathematics"
|
||||
weight = 10
|
||||
nodes = [234, 236, 284]
|
||||
objectives = ["Review floating-point mathematics including IEEE-754.", "Examine `@r` atomic representation of floating-point values.", "Manipulate and convert floating-point values using the `@r` operations.", "Examine `@s` atomic representation of signed integer values.", "Use `+si` to manipulate `@s` signed integer values.", "Define entropy and its source.", "Utilize `eny` in a random number generator (`og`).", "Distinguish insecure hashing (`mug`) from secure hashing (`shax` and friends)."]
|
||||
+++
|
||||
|
||||
# Mathematics
|
||||
|
||||
_This module introduces how non-`@ud` mathematics are instrumented in Hoon. It may be considered optional and skipped if you are speedrunning Hoon School._
|
||||
|
||||
All of the math we've done until this point relied on unsigned integers: there was no negative value possible, and there were no numbers with a fractional part. How can we work with mathematics that require more than just bare unsigned integers?
|
||||
|
Loading…
Reference in New Issue
Block a user