about summary refs log tree commit diff stats
path: root/Readme.md
diff options
context:
space:
mode:
authorKartik K. Agaram <vc@akkartik.com>2016-09-10 10:34:39 -0700
committerKartik K. Agaram <vc@akkartik.com>2016-09-10 10:34:39 -0700
commitc7db6a160a9a43d0905d5dea44e742b47acfa42f (patch)
treef511846d9904670f62284142fe00ad648bc4dd04 /Readme.md
parent3cfa56a923e2ff96c01ba932ecc9cc4ec38e616d (diff)
downloadmu-c7db6a160a9a43d0905d5dea44e742b47acfa42f.tar.gz
3314
Diffstat (limited to 'Readme.md')
-rw-r--r--Readme.md46
1 files changed, 25 insertions, 21 deletions
diff --git a/Readme.md b/Readme.md
index 3333b6e8..e2431191 100644
--- a/Readme.md
+++ b/Readme.md
@@ -144,6 +144,9 @@ Here's a second example, of a function that can take ingredients:
 Functions can specify headers showing their expected ingredients and products,
 separated by `->` (unlike the `<-` in calls).
 
+Once defined, functions can be called just like primitives. No need to mess
+with a `CALL` instruction or push/pop arguments to the stack.
+
 Since Mu is a low-level VM language, it provides extra control at the cost of
 verbosity. Using `local-scope`, you have explicit control over stack frames to
 isolate your functions in a type-safe manner. You can also create more
@@ -295,28 +298,9 @@ and pointers can never be invalidated.
 
 ---
 
-If you're still reading, here are some more things to check out:
-
-a) Look at the [chessboard program](http://akkartik.github.io/mu/html/chessboard.mu.html)
-for a more complex example where I write tests showing blocking reads from the
-keyboard and what gets printed to the screen -- things we don't typically
-associate with automated tests.
-
-b) Try skimming the [colorized source code](https://akkartik.github.io/mu).
-I'd like it to eventually be possible to get a pretty good sense for how
-things work just by skimming the files in order, skimming the top of each file
-and ignoring details lower down. Tell me how successful my efforts are.
-
-c) Try running the tests:
-
-  ```shell
-  $ ./mu test
-  ```
-
-d) Try out the programming environment:
+Mu has a programming environment:
 
   ```shell
-  $ ./mu test edit
   $ ./mu edit
   ```
 
@@ -350,8 +334,28 @@ to browse. To add to the trace, use `stash`. For example:
 Invaluable for understanding complex control flow without cluttering up the
 screen.
 
+---
+
+If you're still reading, here are some more things to check out:
+
+a) Look at the [chessboard program](http://akkartik.github.io/mu/html/chessboard.mu.html)
+for a more complex example where I write tests showing blocking reads from the
+keyboard and what gets printed to the screen -- things we don't typically
+associate with automated tests.
+
+b) Try skimming the [colorized source code](https://akkartik.github.io/mu).
+I'd like it to eventually be possible to get a pretty good sense for how
+things work just by skimming the files in order, skimming the top of each file
+and ignoring details lower down. Tell me how successful my efforts are.
+
+c) Try running the tests:
+
+  ```shell
+  $ ./mu test
+  ```
+
 The next major milestone on Mu's roadmap is dependency-injected interfaces for
-the network and file system.
+the network.
 
 **Credits**