| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
| |
to_string(): relatively stable fields only; for trace()
debug_string(): all fields; for debugging
inspect(): for a form that can be parsed back later
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|