| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
I'm dropping all mention of 'recipe' terminology from the Readme. That
way I hope to avoid further bike-shedding discussions while I very
slowly decide on the right terminology with my students.
I could be smarter in my error messages and use 'recipe' when code uses
it and 'function' otherwise. But what about other words like ingredient?
It would all add complexity that I'm not yet sure is worthwhile. But I
do want separate experiences for veteran programmers reading about Mu on
github and for people learning programming using Mu.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Right now there's now way to tag variables from surrounding spaces
(lexical scopes) as immutable. Should I assume they're immutable unless
the surrounding space is passed out in addition to passed in? What if it
comes from a global?
Or should we explicitly specify modified variables in the header, even
if they'll never be saved anywhere?
We don't use these features much yet, wait until we need it. Mutability
checks are an optional layer and can't cause memory corruption. Lack of
type-checking in the global space, however, *can* cause memory
corruption. That's the biggest open issue right now.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
More bugs fixed in generics to make this work.
|
| | |
|
| |
|
|
|
| |
I'm going to stop wasting precious first-line characters on 'bugfix:'.
It's going to be all bugfixes for a while I think.
|
| |
|
|
| |
Make sure static arrays can take compound types.
|
| |
|
|
|
| |
We're still not done. Layer 60 doesn't yet handle variables in
surrounding spaces. There's probably other issues..
|
| | |
|
| | |
|
| |
|
|
|
| |
Thanks Ella Couch for finding this bug. It's helped me find errors in
mu's code itself.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
I might change my mind on this, but it's worth a try after watching Ella
run up against it today. I got her to build the recipe 'odd?', but then
it failed to run because she couldn't convert a numeric remainder to a
number without a conditional (which I haven't taught her yet).
For now I don't change the value in the boolean, so booleans can store
arbitrary bit patterns like in C. We just say that 0 is false and
anything else is true. I *think* that doesn't break the type system..
|
| | |
|
| |
|
|
|
| |
Only Hide_errors when strictly necessary. In other places let test
failures directly show the unexpected error.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
I really have only one warning left: when somebody redefines a function.
I think I'm going to just turn that into an error as well and drop the
notion of warnings altogether. Anytime we find something wrong we stop
running the program. This is a place where hygiene is justified.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
Very cool that I thought I didn't support type ingredients in arbitrary
positions in container definitions, but I really did. I just didn't have
a test for it, and now I do.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Basically I need to make these tests work:
- Test 1: specializing while saving shape-shifting recipe literal
recipe f a:address:shared:_elem -> b:address:shared:_elem [
local-scope
load-ingredients
reply a
]
recipe main [
local-scope
{x: (recipe (address shared number) -> (address shared number))} <- copy f
y:address:shared:number <- new number:type
*y <- copy 34
z:address:shared:number <- call x, y
$print *z, 10/newline
]
- Test 2: passing recipe literal to higher-order recipe
recipe g x:address:shared:number, {h: (recipe (address shared number) -> (address shared number))} -> y:address:shared:number [
local-scope
load-ingredients
y <- call f, x
]
recipe main [
local-scope
x:address:shared:number <- new number:type
*x <- copy 34
y:address:shared:number <- g x, f
$print *y, 10/newline
]
|
| | |
|
| |
|
|
|
|
| |
I noticed while teaching Ella that when mu encountered a missing recipe
it failed to find *any* recipes after that point, leading to a lot of
spurious errors. Now fixed.
|