| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.)
|
| |
|
|
|
|
| |
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.
|
|
|
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.
|