about summary refs log tree commit diff stats
path: root/045closure_name.cc
Commit message (Collapse)AuthorAgeFilesLines
* 2773 - switch to 'int'Kartik K. Agaram2016-03-131-10/+10
| | | | This should eradicate the issue of 2771.
* 2735 - define recipes using 'def'Kartik K. Agaram2016-03-081-6/+6
| | | | | | | | | | | | 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.
* 2718 - stop crashing on unknown spaceKartik K. Agaram2016-02-261-2/+12
| | | | | I'm going to stop wasting precious first-line characters on 'bugfix:'. It's going to be all bugfixes for a while I think.
* 2712Kartik K. Agaram2016-02-261-13/+13
|
* 2707Kartik K. Agaram2016-02-251-1/+0
|
* 2701 - turn some warnings into errorsKartik K. Agaram2016-02-251-1/+1
| | | | | | | 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.
* 2680Kartik K. Agaram2016-02-201-5/+5
| | | | Delete all the [] that has crept in since 2377 in November.
* 2685Kartik K. Agaram2016-02-191-3/+3
| | | | | | | | | | | | | | | | 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.
* 2631Kartik K. Agaram2016-02-061-0/+4
|
* 2576 - distinguish allocated addresses from othersKartik K. Agaram2016-01-191-12/+14
| | | | | | | | | | | | | | | | This is the one major refinement on the C programming model I'm planning to introduce in mu. Instead of Rust's menagerie of pointer types and static checking, I want to introduce just one new type, and use it to perform ref-counting at runtime. So far all we're doing is updating new's interface. The actual ref-counting implementation is next. One implication: I might sometimes need duplicate implementations for a recipe with allocated vs vanilla addresses of the same type. So far it seems I can get away with just always passing in allocated addresses; the situations when you want to pass an unallocated address to a recipe should be few and far between.
* 2571Kartik K. Agaram2016-01-191-0/+145
| | | | | Reorganize layers in preparation for a better way to manage heap allocations without ever risking use-after-free errors.
* 1768Kartik K. Agaram2015-07-131-133/+0
|
* 1702 - experiment: start using 'ordinal' in namesKartik K. Agaram2015-07-041-14/+14
| | | | | | | It comes up pretty early in the codebase, but hopefully won't come up in the mu level until we get to higher-order recipes. Potentially intimidating name, but such prime real estate with no confusing overloadings in other projects!
* 1599Kartik K. Agaram2015-06-191-6/+6
|
* 1585Kartik K. Agaram2015-06-171-1/+1
|
* 1458Kartik K. Agaram2015-05-251-1/+1
| | | | | | | | | | | | | | | | While pushing out color support in fake screens I realized I've been complecting the special-case of a special-case to transform literal-string arguments for 'new'. As a result I hadn't been catching bad habits like giving its arg the wrong type. Now we have cleaner separation of the two variants of 'new', a few more checks, and better error messages when we mis-call it. Aside: I've added a third goto target. Sliding into spaghetti? Keep an eye on it. This goto might become a common pattern: a layer hooking into a previous one to prevent it from happening. In this case new on literal-strings prevents the transform for new from triggering.
* 1391 - avoid unsigned integersKartik K. Agaram2015-05-171-14/+14
|
* 1387Kartik K. Agaram2015-05-161-1/+1
|
* 1363 - rename 'integer' to 'number'Kartik K. Agaram2015-05-131-7/+7
| | | | ..now that we support non-integers.
* 1343Kartik K. Agaram2015-05-111-1/+1
|
* 1299 - stop using [] in any vectorKartik K. Agaram2015-05-071-1/+1
| | | | | | | | | Useful check: $ grep "[^ '\"]\[[^\"]" *.cc \ |perl -pwe 's/\Wargv\[|\WTests\[|\Wframe\[|\WMemory\[|\WName\[|\WSurrounding_space\[|\WRecipe\[|\WType\[|\WRecipe_number\[|\WType_number\[|\WBefore_fragments\[|\WAfter_fragments\[//g' \ |perl -pwe 's/\Wargv\[|\WTests\[|\Wframe\[|\WMemory\[|\WName\[|\WSurrounding_space\[|\WRecipe\[|\WType\[|\WRecipe_number\[|\WType_number\[|\WBefore_fragments\[|\WAfter_fragments\[//g' \ |grep '[^ ]\['
* 1298 - better ingredient/product handlingKartik K. Agaram2015-05-071-14/+14
| | | | | | | | | | | | | | | | | | | All primitives now always write to all their products. If a product is not used that's fine, but if an instruction seems to expect too many products mu will complain. In the process, many primitives can operate on more than two ingredients where it seems intuitive. You can add or divide more than two numbers together, copy or negate multiple corresponding locations, etc. There's one remaining bit of ugliness. Some instructions like get/get-address, index/index-address, wait-for-location, these can unnecessarily load values from memory when they don't need to. Useful vim commands: %s/ingredients\[\([^\]]*\)\]/ingredients.at(\1)/gc %s/products\[\([^\]]*\)\]/products.at(\1)/gc .,$s/\[\(.\)]/.at(\1)/gc
* 1276 - make C++ version the defaultKartik K. Agaram2015-05-051-0/+133
I've tried to update the Readme, but there are at least a couple of issues.