unisonweb / unisonweb-org Goto Github PK

Source for the unisonweb.org website

License: Other

JavaScript 8.24% CSS 3.44% Vue 65.95% SCSS 22.37%

unisonweb-org's Introduction

⚠️ This repository is no longer active! https://unisonweb.org redirects to https://unison-lang.org which hosts https://github.com/unisonweb/website.

Local Development Environment Setup

Install node 8.13.0
```
brew install n && n 8.13.0
```
Install yarn
```
npm install -g yarn
```

Clone this repository

git clone https://github.com/unisonweb/unisonweb-org.git

Install dependencies
```
cd unisonweb-org && yarn install
```
Create .env file
```
cp .env.example .env
```
Update .env variables
```
ALGOLIA_INDEX_NAME=
ALGOLIA_APP_ID=
ALGOLIA_SEARCH_ONLY_KEY=
ALGOLIA_ADMIN_KEY=
```
These variables can be found in the following locations:
- The "API Keys" page in the Alogia app.
- The "Environment" section of Settings > Build & Deploy in the Netlify Dashboard.
Install gridsome

yarn global add @gridsome/cli

Start local webserver
```
gridsome develop
```

Netlify Hosting

Adding New Members

New members may be added to Netlify on the "Members" tab of the Unison Computing team.

Snippet Injection

Script analytics may be added to the site on the "Post processing" section of Settings > Build & Deploy in the Netlify Dashboard.

Documentation: https://www.netlify.com/docs/inject-analytics-snippets

Deploy Contexts

A new build is deployed every time the GitHub repo changes.
Each build gets a unique URL to preview changes.
All deploys can be viewed on the "Deploys" tab".
Click any deploy to see the deploy log. From the deploy log screen, click "Preview deploy" to see what's been built.
To publish changes to the live site, simply merge them into the production branch.

Form processing

Form submissions are stored in the "Forms" tab.
Outgoing notifications for form submiossions can be configured on the "Form notifications" section of Settings > Forms.
Form data may be piped into 3rd party applications (i.e. Mailchimp, Sendgrid, Google Sheets) by connecting with a Zapier account.

Flipping DNS

Add a custom domain.
In your DNS settings, add a CNAME record with a name of "www" and a value of "unisoncomputing-com.netlify.com".
Wait for DNS to propogate (usually < 5 mins).
Website is live.

Content Editing

All editable content is located in src/data/.

Cookies Notice The wording for the cookies notice can be found in src/data/components/cookies-notice.yml.
Site Navigation A list of links can be found in src/data/components/site-nav.yml.
Docs Sidebar A list of links can be found in src/data/components/doc-sidebar.yml.
Docs Pages Page content is stored as markdown in src/data/docs/.

Each markdown file must include frontmatter with title and description properties. These properties are used in the <title> and <meta name="description"> tags in the <head> of each page:
```
---
title: An Interesting Title
description: Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.
---
```
Blog Posts Post content is stored as markdown in src/data/blog/posts/. Each markdown file should be named index.md and placed into folder (along with related images) named like so:

2019-04-04-writeup-of-our-first-unison-meetup

This ^ naming convention will yield the following permalink: www.unisonweb.org/2019/04/04/writeup-of-our-first-unison-meetup

In addition to the title and description properties, each markdown file's frontmatter must also include a date, author, slug (used to form the URL), and categories property:
```
---
slug: first-unison-meetup
title: Writeup of our first Unison meetup
description: placeholder
date: 2019-04-04
author: Paul Chuisano
categories: ["news"]
---
```
Blog Categories Categories are defined as markdown files in src/data/blog/categories/.

Each markdown file's frontmatter should include id, title, emoji, and color properties like so:
```
---
id: engineering
title: Engineering
emoji: ⚛️
color: pink
---
```
The value for the color property should match the name of a color defined in src/data/colors.yml.

Website Colors

The names and hex values for all colors used across the site are located in src/data/colors.yml. To change a color, simply call the palette() function with the name the color you'd like to reference.

.element {
  color: palette(purple);
}

By default, the palette() function will return the base hex value (defined the src/data/colors.yml). Optionally, you may pass a second argument to return the value of the related tone.

.element {
  color: palette(blue, dark);
}

All available tones are defined in src/assets/styles/config/_palettes.scss, and are listed below for your convenience:

xxx-dark: 80% dark
xx-dark: 55% dark
x-dark: 45% dark
dark: 20% dark
mid: 20% light
light: 45% light
x-light: 60% light
xx-light: 75% light
xxx-light: 90% light

Codeblocks

Codeblocks may include (optional) frontmatter for altering their appearance:

```unison
---
title: output
filename: filename
---
42, 9.7, 1e100, "hello", +99, -42, true, false -- various literals
```

title can be any value with eight (8) characters or less. If the value of the title is set to output or ucm, the codeblock will be rendered with an alternate icon.

filename can be any value with fifty (50) characters or less.

By default, codeblocks are rendered with line numbers. Line numbers may optionally be changed to carets with show-carets: true, or hidden altogether with show-numbers: false.

Colors for syntax highlighting in codeblocks are defined in src/assets/styles/common/codeblock/_tokens.scss:

.token {

  @at-root .un-codeblock & {

    &.comment { color: palette(gray, light); }
    &.char {}
    &.string { color: palette(black); }
    &.keyword { color: palette(green); }
    &.import_statement {}
    &.builtin { color: palette(blue); }
    &.number { color: palette(green); }
    &.operator { color: palette(green); }
    &.hvariable { color: palette(gray, xx-dark); }
    &.constant { color: palette(purple); }
    &.punctuation { color: palette(pink); }

  }
}

Regex patterns to identify tokens are defined here: https://github.com/unisonweb/prism/blob/master/components/prism-unison.js.

Eventually, the regex patterns need to be updated to match the Unison language. Once complete, a PR should be submitted to include Unison syntax highlighting in the main repository.

unisonweb-org's People

Contributors

Stargazers

Watchers

unisonweb-org's Issues

use === in testing docs

Since unisonweb/base#20 base has included an === function that provides helpful output when the two values are not equal. The current testing doc uses == in several places and has a note about how it doesn't provide helpful output if the values don't match. It would probably make sense to simplify the page and use ===.

I didn't make a PR because I wasn't sure what the process was for the docs. The README mentions Algolia API keys; are those necessary for local development? I tried just running ucm transcript but base wasn't in scope, so I suspect that I was going about this right.

Fill in rest of UCM command reference

Source is here.

https://github.com/unisonweb/unisonweb-org/blob/master/src/data/docs/commands.md

Current (incomplete) rendered version is live at: https://www.unisonweb.org/docs/commands

We need an entry for each of the commands that show up in ucm help. Commands can just be listed alphabetically.

Template for each entry is just:

## `<commandname>` (or `<alias1>`, `<alias2>`)

Insert verbiage explaining the command. Use links to other commands, and link to other relevant info on this documentation site. Note, when using links, use links relative to this site (so like `/docs/refactoring` rather than  `https://unisonweb.org/docs/refactoring`)

### FAQ about the `<commandname>`  command 

#### Why does it frobnicate?

#### What happens if xyz?

  add
  `add` adds to the codebase all the definitions from the most recently typechecked file.
  
  alias.term
  `alias.term foo bar` introduces `bar` with the same definition as `foo`.
  
  alias.type
  `alias.type Foo Bar` introduces `Bar` with the same definition as `Foo`.
  
  builtins.merge
  Adds all the builtins to `builtins.` in the current namespace.
  
  builtins.update
  Adds all the builtins that are missing from this namespace, and deprecate the ones that don't
  exist in this version of Unison.
  
  copy.patch
  `copy.patch foo bar` copies the patch `bar` to `foo`.
  
  debug.history
  Dump codebase history, compatible with bit-booster.com/graph.html
  
  delete
  `delete foo` removes the term or type name `foo` from the namespace.
  
  delete.namespace
  `delete.namespace <foo>` deletes the namespace `foo`
  
  delete.patch
  `delete.patch <foo>` deletes the patch `foo`
  
  delete.term
  `delete.term foo` removes the term name `foo` from the namespace.
  
  delete.type
  `delete.type foo` removes the type name `foo` from the namespace.
  
  display (or show)
  `display foo` prints a rendered version of the term `foo`.
  
  display.to
  `display.to <filename> foo` prints a rendered version of the term `foo` to the given file.
  
  docs
  `docs foo` shows documentation for the definition `foo`.
  
  edit
  `edit foo` prepends the definition of `foo` to the top of the most recently saved file.
  
  find
  `find`          lists all definitions in the current namespace.
  `find foo`      lists all definitions with a name similar to 'foo' in the current namespace.
  `find foo bar`  lists all definitions with a name similar to 'foo' or 'bar' in the current
                  namespace.
  
  find.patch (or list.patch, ls.patch)
  `find.patch`  lists all patches in the current namespace.
  
  find.verbose (or list.verbose, ls.verbose)
  `find.verbose` searches for definitions like `find`, but includes hashes and aliases in the
  results.
  
  fork (or copy.namespace)
  `fork src dest` creates the namespace `dest` as a copy of `src`.
  
  help (or ?)
  `help` shows general help and `help <cmd>` shows help for one command.
  
  history
  `history`                     Shows the history of the current path.
  `history .foo`                Shows history of the path .foo.
  `history #9dndk3kbsk13nbpeu`  Shows the history of the namespace with the given hash. The full
                                hash must be provided.
  
  link
  `link src dest` creates a link from `src` to `dest`. Use `links src` or `links src <type>` to
  view outgoing links, and `unlink src dest` to remove a link.
  
  links
  `links src`        shows all outgoing links from `src`.
  `links src <type>` shows all links for the given type.
  
  list (or ls)
  `list`       lists definitions and namespaces at the current level of the current namespace.
  `list foo`   lists the 'foo' namespace. `list .foo`  lists the '.foo' namespace.
  
  merge
  `merge src`      merges `src` namespace into the current namespace
  `merge src dest` merges `src` namespace into the `dest` namespace
  
  merge.preview
  `merge.preview src`      shows how the current namespace will change after a `merge src`.
  `merge.preview src dest` shows how `dest` namespace will change after a `merge src dest`.
  
  move.namespace (or rename.namespace)
  `move.namespace foo bar` renames the path `bar` to `foo`.
  
  move.patch (or rename.patch)
  `move.patch foo bar` renames the patch `bar` to `foo`.
  
  move.term (or rename.term)
  `move.term foo bar` renames `foo` to `bar`.
  
  move.type (or rename.type)
  `move.type foo bar` renames `foo` to `bar`.
  
  names
  `names foo` shows the hash and all known names for `foo`.
  
  namespace (or cd, j)
  `namespace foo.bar`   descends into foo.bar from the current namespace.
  `namespace .cat.dog`  sets the current namespace to the abolute namespace .cat.dog.
  
  patch
  `patch` rewrites any definitions that depend on definitions with type-preserving edits to use the
  updated versions of these dependencies.
  
  pull
  The `pull` command merges a remote namespace into a local namespace.
  `pull remote local`  merges the remote namespace `remote` into the local namespace `local`.
  `pull remote`        merges the remote namespace `remote` into the current namespace
  `push`               merges the remote namespace configured in `.unisonConfig` with the key
                       `GitUrl.ns` where `ns` is the current namespace, into the current namespace
  where `remote` is a git repository, optionally followed by `:` and an absolute remote path, such
  as: `https://github.com/org/repo` `https://github.com/org/repo:.some.remote.path`
  
  push
  The `push` command merges a local namespace into a remote namespace.
  `push remote local`  merges the contents of the local namespace `local` into the remote namespace
                       `remote`.
  `push remote`        publishes the current namespace into the remote namespace `remote`
  `push`               publishes the current namespace into the remote namespace configured in
                       `.unisonConfig` with the key `GitUrl.ns` where `ns` is the current namespace
  where `remote` is a git repository, optionally followed by `:` and an absolute remote path, such
  as: `https://github.com/org/repo` `https://github.com/org/repo:.some.remote.path`
  
  quit (or exit, :q)
  Exits the Unison command line interface.
  
  reflog
  `reflog` lists the changes that have affected the root namespace
  
  replace.term
  `replace.term <from> <to> <patch>`  Replace the term <from> in the given patch with the term
                                      <to>.
  `replace.term <from> <to>`          Replace the term <from> with <to> in the default patch.
  
  replace.type
  `replace.type <from> <to> <patch>`  Replace the type <from> in the given patch with the type
                                      <to>.
  `replace.type <from> <to>`          Replace the type <from> with <to> in the default patch.
  
  reset-root
  `reset-root .foo`                Reset the root namespace (along with its history) to that of the
                                   `.foo` namespace.
  `reset-root #9dndk3kbsk13nbpeu`  Reset the root namespace (along with its history) to that of the
                                   namespace with hash `#9dndk3kbsk13nbpeu`.
  
  run
  `run mymain`  Runs `!mymain`, where `mymain` is searched for in the most recent typechecked file,
                or in the codebase.
  
  test
  `test` runs unit tests for the current branch.
  
  todo
  `todo`                 lists the refactor work remaining in the default patch for the current
                         namespace.
  `todo <patch>`         lists the refactor work remaining in the given patch in the current
                         namespace.
  `todo <patch> [path]`  lists the refactor work remaining in the given patch in given namespace.
  
  undo
  `undo` reverts the most recent change to the codebase.
  
  unlink (or delete.link)
  `unlink src dest` removes a link from `src` to `dest`.
  
  update
  `update` works like `add`, except that if a definition in the file has the same name as an
  existing definition, the name gets updated to point to the new definition. If the old definition
  has any dependents, `update` will add those dependents to a refactoring session, specified by an
  optional patch.
  `update`                  adds all definitions in the .u file, noting replacements in the default
                            patch for the current namespace.
  `update <patch>`          adds all definitions in the .u file, noting replacements in the
                            specified patch.
  `update <patch> foo bar`  adds `foo`, `bar`, and their dependents from the .u file, noting any
                            replacements into the specified patch.
  
  view
  `view foo` prints the definition of `foo`.
  
  view.patch
  `view.patch`          Lists all the edits in the default patch.
  `view.patch <patch>`  Lists all the edits in the given patch.

`bug` doesn't exist in M1i

It looks like bug() isn't in ucm M1i, so the testing docs don't work 😞

❯ ucm --version
ucm version: release/M1i

[hack hack use the brokenReverse code]

❯ ucm

   _____     _             
  |  |  |___|_|___ ___ ___ 
  |  |  |   | |_ -| . |   |
  |_____|_|_|_|___|___|_|_|
  
  Welcome to Unison!
  
  I'm currently watching for changes to .u files under ~
  
  Type help to get help. 😎

.> 

  I'm not sure what bug means at line 18, columns 5-8
  
     18 |     bug ("Not equal!", expected, actual)
  
  Whatever it is, it has a type that conforms to (base.Text, [base.Nat], [base.Nat]) -> base.Boolean.

Document Transcript Usage

Summary: we should document what transcripts are and how to use them on the website.

Transcripts are a really neat feature of Unison. They can/could be used for:

Bug reporting
Testing
Documentation/tutorials/literate programming

If you run ucm --help transcript or ucm --help transcript.fork you get a bit of help about the transcript command, but currently there doesn't seem to be any docs about transcripts on the website.

We have some examples of transcripts here that could be used as examples to assist in documenting how transcripts can be used. But transcripts could probably also be used in lots of other creative ways, and I'd love for people to explore that space.

Algolia not indexing beyond depth 2 headings

I tried altering this but it seems to have had no effect: https://github.com/unisonweb/unisonweb-org/blob/master/config/algolia.js#L10

@brianfryer can you take a look at this, I'd say it's pretty high priority as search is not very useful in its current state

Create a doc of a basic file I/O program

I'm not sure if Unison is currently actually capable of any sort of file I/O. I see likely candidates inside base.io but as a non-PLs person I am at the level of "I think I can read this code and it looks really cool" but not "I can look at a function and figure out how to write a program with it".

I think a step-by-step doc which can open a file (or read from stdin) and then do some basic transformation (convert to all caps, find a substring and change it...) would go a long way to move my, and hopefully others, understanding of what a program past just pure functions like square would look like.

RFC: reorg of docs sidebar

Here's a proposal. We would collapse some of the stuff that's currently spread over multiple markdown files into one file. Breaking things into multiple files was done initially to support full text search, but then we didn't even end up supporting that and there's a better way to support full-text search of larger documents. We should just do that rather than contorting the content.

This makes the sidebar a lot more useful as an overview of the docs content. Some of the items under each heading just meant to be suggestive.

Getting started

Welcome
Roadmap
Quickstart
A tour of Unison

Guides

Distributed computing primitives
Pull requests and collaboration
Publishing and sharing libraries
Transcripts: executable tutorials
First-class documentation with live examples
Refactoring
Abilities and handlers
...

Worked examples

A distributed map reduce library
Spark as a library
A scalable distributed key value store
...

References

About
Lanugage reference
Base libraries
UCM command reference
UCM tips
An annotated bibliography
FAQ

Error in the stream example of the abilities section

While reading the Abilities in Unison section, I tried to run the following example:

structural ability Stream e where
  emit : e ->{Stream e} ()
  -- equivalently
  -- emit : e -> ()

Stream.range : Nat ->{} Nat ->{Stream Nat} ()
Stream.range n m =
  if n >= m then ()
  else
    emit n
    Stream.range (n + 1) m

However, I got the following error

The else clause of an if expression needs to
  have the same type as the then clause.

  Here, one   is:  Unit
  and another is:  Unit ->{Stream Nat} Unit


      8 |   if n >= m then ()
      9 |   else
     10 |     emit n
     11 |     Stream.range (n + 1) m

From the error message, I figured out I can replace the last line of the range definition by

Stream.range (n + 1) m ()

but this seems weird to me.

In case this is helpful, I am running release/M2j (built on 2021-10-07).

New User Feedback

Hi! I came across Unison based on reading about Effects Systems. I know that it is sometimes hard to get feedback from new or potential users so I try to do my best share my experience when I'm checking out something new. Maybe this experience report is helpful, but if it's not, feel free to disregard.

Based on my interest in checking out Unison, I ended up at https://www.unison-lang.org/learn/ which looks great. Before installing Unison, I was interested in reading more about what problems the language targets. I clicked on "What's next" since that's the only apparent action that might lead to more info. It turns out "What's next" doesn't navigate anywhere. Regretfully, I ended up clicking on the install link instead. After scrolling to the bottom of the install page, I did find link to https://www.unison-lang.org/learn/the-big-idea/ which is what I was looking for. The big idea post is really helpful. It may help to link to it directly from the learn page or even embed a short summary.

After reading about the big idea, I was still interested to learn more. The "Where to next" section gives links to talks and more info on the code base manager. Since I came to unison based on a reference about Effects Systems, I felt like I was at somewhat of dead end. What I wanted was a table of contents so that I can read more about effects systems. The links at the top of the page didn't seem to help me find what I was looking for either. It turns out that there is a very helpful table contents, but since I was looking at the page on my laptop, the screen wasn't wide enough for the table of contents to appear. The table of contents is accessible via the hamburger. As a site note, clicking on the sections inside the table of contents scrolls the window which makes it harder to explore.

Anyway, hopefully this feedback provides some utility. I'm looking forward to learning more about Unison.

The description of Escape Sequences in the reference is missing a bunch

The current list contains the single-character C escapes (\b, \r, \n etc). It's missing

two character specials: \LF, \CR, \FF, \VT, \SP, \BS, \HT
decimal escapes: \ddd
hex escapes: \xdd
octal escapes: \oddd

(Guess who's writing a SkyLighting syntax for Unison... :)

"line comment" language reference text seems wrong

The current Unison language reference says line comments begin with "--(any char sequence)" and can only otherwise contain whitespace.

Discussion on the Unison slack leads me to believe that line comments can indeed be preceded by anything. So it's valid to have

DEFAULT_AGE = 16 -- this is default age because it's the minimum legal driving age in the US

Language ref should be updated accordingly.

Wrong "Where to next?" article in Learn section

I suppose all "Where to next?" links should guide learner through the textbook, but I noticed that I missed an article while following them.

transcript doc: suggest builtins.merge?

The current transcript doc states the following:

Note that unlike the default behavior of initializing a new codebase with the UCM codebase-create argument, transcripts do not contain the base library. If you would like your codebase to run against a codebase with the base library in scope, you can add a ucm block which issues a pull command for your desired base library.

I'd like it to be super fast/simple for people to be able to create transcripts to play around with the language or submit bug reports. Pulling in base really slows down a transcript. But it feels kind of wrong that by default you can't even reference Nat in a transcript.

Should we add a piece to the document about how if you aren't pulling in base you might want to add .> builtins.merge to the top of your document so you can use builtin types?

It also feels off that you might have to separately do .> builtins.mergio if you want those types as well. Especially since Failure is (for some reason???) defined within the io namespace even though Exception isn't. I tried builtins.update which sounded like it should do what I wanted, but it gave an error saying that it's not implemented yet.

I almost wonder if transcripts should merge builtins by default and you can use a flag to disable the behavior if you are going to bring in base. But this might be confusing for users.

@aryairani @rlmark what do you think? Honestly I don't know whether this is an issue for the website or for ucm itself :)

Add a link to the editor setup instructions to the quickstart guide

They are at https://www.unisonweb.org/docs/editor-setup/

Not sure if it needs to be some kind of internal link or what, to avoid breaking later?

Quickstart suggests to create a directory

Create a new directory, unisoncode (or any name you choose), then run the ucm init binary from within that directory. You'll see a note about "No codebase exists here so I'm initializing one..." and a welcome screen.

That's not what happens with the latest version.

There's no need to create a directory, ucm init will initialize a codebase in $HOME/.unison.
The output of ucm init is different.

Add destructuring binds to language reference

The language reference at https://www.unisonweb.org/docs/language-reference/ doesn't include syntax for destructuring binds like this:

foo : (a, b) -> a
foo p = 
  (a,b) = p
  a

link to https://github.com/unisonweb/unison on webpage

Normally, there's a prominent link to the github page for contributors and interested people.
Currently, there's only a small link to this repo. Would be nice to be directed directly to the "meat" of it all.

Update docs to reflect new `match .. with` / `cases` syntax

This change should be made concurrently with the next release (M1i?).

Some UI glitches: headings that don't fit on 1 line become multicolumn

See this comment and screenshots there: #35 (comment)

@brianfryer when you have a chance to fix this, you can also uncomment the stuff I temporarily commented out in the sidebar just to make the sidebar shorter than the content - https://github.com/unisonweb/unisonweb-org/blob/master/src/data/layouts/partials/doc-sidebar.yml

`ucm` fenced code blocks should get a block type of `ucm`, not `code`

For instance here

Misleading marketing related to builds

From the frontpage:

We simplify codebase management — Unison has no builds, no dependency conflicts, and renaming things is trivial.

"Unison has no builds" is misleading because it implies that unison is doing something fancier than it's actually doing - it's just an interpreted language so of course there's no build step. "no dependency conflicts, and renaming things" are both novel unison innovations, "no builds" being put right next to them implies it's novel too.

If the goal was to have three items for aesthetic appeal, can I suggest "Unison has no dependency conflicts, renaming things is trivial, and the same test never runs twice"?

I mean, you can kind of technically argue that even interpreted languages have builds in a way that unison doesn't, since they need to convert the text into an AST (and maybe even typecheck) before executing. And for some reason almost no statically typed languages are interpreted, so it's worth mentioning somewhere. But if I were trying to communicate the most exciting features of Unison I'd pick something else

Blog feed?

Hi! I'm really excited about Unison. Unfortunately, I couldn't find RSS/Atom feed of the blog. Could you tell where to find it, or add one if it doesn't exist yet?

Language reference page on types omits user-defined types

The page covering Unison's type system conspicuously omits any discussion of user-defined types, which are covered in their own page titled in the sidebar as "Type Declarations". IMO, there should be at least some mention of user-defined types on the "Types" page, with links back to the other page for details. Without this, I had a hard time re-finding the section on record types.

Define whitespace in language reference

The language reference at https://www.unisonweb.org/docs/language-reference/ uses the term "whitespace" in several places, but doesn't define what that means.

Clarify evaluation order in language ref

Aaron Sikes brought this up in Slack:

The evaluation semantics of function application is applicative order Call-by-Value. In the expression f x y, x and y are fully evaluated in left-to-right order, then f is fully evaluated, then x and y are substituted into the body of f, and lastly the body is evaluated

Originally I was thinking this should be changed to:

The evaluation semantics of function application is applicative order Call-by-Value. In the expression f x: f is fully evaluated, then x, then x is substituted into the body of f, and lastly the body is evaluated. This rule also covers expressions like g a b, which are parsed as (g a) b.

But I don't think we want to guarantee one at a time evaluation order like this. For instance, consider:

g x = 
  Stream.emit 1
  (y -> 12)

> Stream.toList 'let g (Stream.emit 0) (Stream.emit 2)

This currently will produce [0,2,1] - it evaluates left to right all the arguments being supplied, and then does substitutions and evaluation of the body. And this is what you want, since the one at a time order is crazy inefficient and would involve building N temporary closures just to pass N args to a function. I don't think any real language uses this.

So I think maybe the current description is not bad.

Doc issue: wrong url for pulling base

On this page: https://www.unison-lang.org/learn/ucm-commands/pull/

It recommends the command pull unison.public.base.releases.latest lib.base, which yields:

.> pull unison.public.base.releases.latest lib.base

  Downloaded 0 entities.

  ❗️

  The server didn't find anything at
  unison.public.base.releases.latest

I believe this should instead be pull unison.public.base.latest lib.base.

Tour description doesn't match tour code example

I was reading "A tour of Unison" and found this part:

Now put the following in your scratch file:

square : [Nat](https://share.unison-lang.org/latest/types/@@Nat) -> [Nat](https://share.unison-lang.org/latest/types/@@Nat)
square x =
  use Nat *
  x [*](https://share.unison-lang.org/latest/terms/@@Nat.*) x
This defines a function called
square
.It takes an argument called
x
and it returns
x
multiplied by itself.

The first line,
use .base
,tells Unison that you want to use short names for the base libraries in this file (which allows you to say
[Nat](https://share.unison-lang.org/latest/types/@@Nat)
instead of having to say
base.Nat
).

The lower text mentions use .base, but that is not mentioned in the snippet.

Track Unison libraries in a manageable database

The unison github wiki currently tracks Unison libraries under development.

In the long-term, it would be better if this catalog appeared somewhere on unisonweb.org. As the catalog grows, it will be also be useful for it to be stored in a uniform, easily maintainable database as suggested by @theduke. The database could be as simple as a github repo containing a json "database", like Nim's package database. A simple web client, similar to Nim's nimble.directory package viewer, would make it possible to view/browse the database in a developer-friendly way.

A more Unison-y long-term solution would be to store the package database as a value in a Unison codebase as exemplified here or in a typed, distributed data store (once such a Unison-native capability has been developed).