| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
| |
Thanks Juan Crispin Hernandez for the suggestion.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Periodic cleanup to replace 'reply' with 'return' everywhere in the
repo.
I use 'reply' for students to help reinforce the metaphor of function
calls as being like messages through a pipe. But that causes 'reply' to
get into my muscle memory when writing Mu code for myself, and I worry
that that makes Mu seem unnecessarily alien to anybody reading on
Github.
Perhaps I should just give it up? I'll try using 'return' with my next
student.
|
| |
|
|
|
|
|
|
| |
Let's constrain 'push' on lists to always modify its ingredient.
That makes some possibilities more verbose, such as lists that share a
common tail. But may be worthwhile to get better errors in the common
use-case.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
A long-standing problem has been that I couldn't spread code across
'run' blocks because they were separate scopes, so I've ended up making
them effectively comments. Running code inside a 'run' block is
identical in every way to simply running the code directly. The 'run'
block is merely a visual aid to separate setup from the component under
test.
In the process I've also standardized all Mu scenarios to always run in
a local scope, and only use (raw) numeric addresses for values they want
to check later.
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
Stop checking the number of ingredients and products when picking
shape-shifting recipes. That's more consistent with how we handle
regular recipes, and we still get errors in all the examples I can think
of:
reverse # no ingredients or products
n:num <- length # no ingredients; products don't provide type
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Can't use type abbreviations inside 'memory-should-contain'.
|
| |
|
|
|
|
|
| |
Process type abbreviations in function headers.
Still a couple of places where doing this causes strange errors. We'll
track those down next.
|
| | |
|
| | |
|
| |
|