about summary refs log tree commit diff stats
path: root/060immutable.cc
Commit message (Collapse)AuthorAgeFilesLines
* 2735 - define recipes using 'def'Kartik K. Agaram2016-03-081-42/+42
| | | | | | | | | | | | 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.
* 2728 - don't ignore /space: while checking typesKartik K. Agaram2016-03-041-16/+1
|
* 2727 - don't ignore /space: in immutability checksKartik K. Agaram2016-03-041-12/+50
| | | | | | | | | | | | | | | 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.
* 2726Kartik K. Agaram2016-03-041-3/+4
|
* 2716 - more holes in immutability checksKartik K. Agaram2016-02-261-6/+97
| | | | | We're still not done. Layer 60 doesn't yet handle variables in surrounding spaces. There's probably other issues..
* 2715 - bugfix: directly modifying ingredientsKartik K. Agaram2016-02-261-0/+24
|
* 2712Kartik K. Agaram2016-02-261-6/+6
|
* 2709Kartik K. Agaram2016-02-251-6/+0
| | | | | Only Hide_errors when strictly necessary. In other places let test failures directly show the unexpected error.
* 2701 - turn some warnings into errorsKartik K. Agaram2016-02-251-25/+25
| | | | | | | 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.
* 2670 - better names for string conversionsKartik K. Agaram2016-02-191-1/+1
| | | | | | to_string(): relatively stable fields only; for trace() debug_string(): all fields; for debugging inspect(): for a form that can be parsed back later
* 2685Kartik K. Agaram2016-02-191-4/+4
| | | | | | | | | | | | | | | | 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.
* 2656Kartik K. Agaram2016-02-141-4/+1
|
* 2576 - distinguish allocated addresses from othersKartik K. Agaram2016-01-191-36/+36
| | | | | | | | | | | | | | | | 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.
* support immutability checks in sandbox/ appKartik K. Agaram2015-12-151-1/+28
|
* bugfix after commit 2612Kartik K. Agaram2015-12-151-0/+21
|
* improve error messageKartik K. Agaram2015-12-151-8/+16
|
* infect immutability across recipesKartik K. Agaram2015-12-151-2/+47
| | | | | | | | | | | | | | | | | If a product is contained-in some ingredient, then the caller will check the product for mutations as well. For example, consider this linked-list operation: b:address:list:number <- next a:address:list:number If 'a' is immutable in the surrounding recipe, you probably want 'b' to be immutable as well. You can achieve this by giving 'next' the following header (ignoring shape-shifting): recipe next a:address:list:number -> b:address:list:number/contained-in:a This is the theory, anyway. Rather to my surprise, this doesn't trigger any issues with existing code. That's probably too good to be true.
* next baby step: infect immutability across copiesKartik K. Agaram2015-12-151-15/+54
|
* experiment: treat pure ingredients as immutableKartik K. Agaram2015-12-151-0/+211
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This isn't complete yet: a) If you copy a variable the copy is not checked for mutations. b) /contained-in might be a hack. It's needed because sometimes I want to pass in two pointers to a data structure, say for deleting something from a list. Both are conceptually the same structure, so it's unnecessary for both to be products as well. There's also technical reasons you *can't* return both, because if you pass in the same variable to both ingredients (say you want to remove the first element of a list), the products now must write to the same variable as well (thanks to our earlier /same-as-ingredient constraint), and what value gets written last is not something we want to be thinking about. c) Even if we stick with /contained-in, it's ambiguous. I'm using it sometimes to say "a belongs to b", sometimes to say "a _will_ belong to b after the recipe returns. Perhaps that distinction doesn't matter. We'll see. d) Should we be encouraged to say ingredients are contained in products? At the moment 'push' works only because of mu's incomplete analysis. Once we fix a) above, it's unclear what the right header should be. e) edit/ isn't close to working yet. (No more commit numbers since I'm now starting a branch, and can't rely on a stable ordering as I rebase. For the same reason I'm not including the changes to .traces/, to minimize merge conflicts.)
* 2433 - temporarily undo 2432Kartik K. Agaram2015-11-131-211/+0
| | | | | | Lessons with Caleb uncovered a problem with type ingredients: I can call shape-shifting recipes like 'push' from the commandline but not inside the edit/ or sandbox/ apps.
* 2432 - first stab at making ingredients immutableKartik K. Agaram2015-11-131-0/+211
The rule is, an address ingredient is only modifiable if: a) it's also a product b) it's /contained-in some other ingredient+product Only if an ingredient is a modifiable can you: a) call get-address or index-address on it (the only way to write to it) b) call other recipes that also return it in a product I still don't check copies of the address. That's next. Core mu passes this check, but none of the example apps do. edit/ and sandbox/ are known to fail.