| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
This should eradicate the issue of 2771.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
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..
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
]
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
All my attempts at staging this change failed with this humongous commit
that took all day and involved debugging three monstrous bugs. Two of
the bugs had to do with forgetting to check the type name in the
implementation of shape-shifting recipes. Bug #2 in particular would
cause core tests in layer 59 to fail -- only when I loaded up edit/! It
got me to just hack directly on mu.cc until I figured out the cause
(snapshot saved in mu.cc.modified). The problem turned out to be that I
accidentally saved a type ingredient in the Type table during
specialization. Now I know that that can be very bad.
I've checked the traces for any stray type numbers (rather than names).
I also found what might be a bug from last November (labeled TODO), but
we'll verify after this commit.
|
| |
|
|
|
|
|
| |
Start using type names from the type tree rather than the property tree
in most places. Hopefully the only occurrences of
'properties.at(0).second' left are ones where we're managing it. Next we
can stop writing to it.
|
| |
|
|
| |
Include type names in the type tree. Though we aren't using them yet.
|
| |
|
|
| |
It's only for transient debugging.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Stack of plans for cleaning up replace_type_ingredients() and a couple
of other things, from main problem to subproblems:
include type names in the type_tree rather than in the separate properties vector
make type_tree and string_tree real cons cells, with separate leaf nodes
redo the vocabulary for dumping various objects:
do we really need to_string and debug_string?
can we have a version with *all* information?
can we have to_string not call debug_string?
This commit nibbles at the edges of the final task, switching from
member method syntax to global function like almost everything else. I'm
mostly using methods just for STL in this project.
|
| |
|
|
|
| |
I was finding it hard to wrap around the directionality of calls with
'lhs' and 'rhs'. Seems to work better with 'to' and 'from'. Let's see.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Still need to type-check it, though.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
We want to use the type 'recipe' for recipe *variables*, because it
seems nicer to say `recipe number -> number` rather than recipe-ordinal,
etc. To support this we'll allow recipe names to be mentioned without
any type.
This might make a couple of places in this commit more brittle. I'm
dropping error messages, causing them to not happen in some situations.
Maybe I should just bite the bullet and require an explicit
:recipe-literal. We'll see.
|
|
|
Reorganize layers in preparation for a better, more type-safe
implementation of first-class and higher-order recipes.
|