about summary refs log tree commit diff stats
path: root/061recipe.cc
Commit message (Collapse)AuthorAgeFilesLines
* 2803Kartik K. Agaram2016-03-211-2/+2
| | | | | Show more thorough information about instructions in the trace, but keep the original form in error messages.
* 2773 - switch to 'int'Kartik K. Agaram2016-03-131-1/+1
| | | | This should eradicate the issue of 2771.
* 2735 - define recipes using 'def'Kartik K. Agaram2016-03-081-12/+12
| | | | | | | | | | | | 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.
* 2712Kartik K. Agaram2016-02-261-5/+5
|
* 2711 - permit boolean<-number conversionsKartik K. Agaram2016-02-251-6/+6
| | | | | | | | | | | 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..
* 2695 - todo for recipe variablesKartik K. Agaram2016-02-231-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 ]
* 2681 - drop reagent types from reagent propertiesKartik K. Agaram2016-02-211-1/+0
| | | | | | | | | | | | | | | | | 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.
* 2678Kartik K. Agaram2016-02-201-10/+9
| | | | | | | 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.
* 2677Kartik K. Agaram2016-02-201-1/+1
| | | | Include type names in the type tree. Though we aren't using them yet.
* 2671 - never use debug_string() in tracesKartik K. Agaram2016-02-191-1/+1
| | | | It's only for transient debugging.
* 2685Kartik K. Agaram2016-02-191-2/+2
| | | | | | | | | | | | | | | | 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.
* 2620Kartik K. Agaram2016-01-301-6/+6
| | | | | 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.
* 2614Kartik K. Agaram2016-01-291-1/+1
|
* 2570 - recipe variables are now fully type-checkedKartik K. Agaram2016-01-181-0/+31
|
* 2569Kartik K. Agaram2016-01-181-0/+14
|
* 2566 - typecheck 'call' on recipe variablesKartik K. Agaram2016-01-181-1/+25
|
* 2565 - typecheck 'call' on literal recipesKartik K. Agaram2016-01-181-0/+48
|
* 2563 - bring back 'call'Kartik K. Agaram2016-01-181-0/+54
| | | | Still need to type-check it, though.
* 2562Kartik K. Agaram2016-01-171-11/+12
| | | | | | | | | | | | 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.
* 2561Kartik K. Agaram2016-01-171-0/+25
Reorganize layers in preparation for a better, more type-safe implementation of first-class and higher-order recipes.