| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
| |
Great that it just worked after the previous commit.
|
| |
|
|
|
| |
Starting to leave debug prints around once again, just in case one of
them is worth promoting to the trace..
|
| |
|
|
| |
Yet another bugfix as I trace through the last session with Caleb.
|
| |
|
|
|
| |
Another little bit of polish: if a call doesn't do enough for a complete
specialization, show a decent error message and above all: don't die!
|
| |
|
|
|
|
| |
Fix the drawback in the previous commit: if an ingredient is just a
literal 0 we'll skip its type-checking and hope to map type ingredients
elsewhere.
|
| |
|
|
|
|
|
|
|
| |
I was failing to specialize calls containing literals. And then I had to
deal with whether literals should map to numbers or characters. (Answer:
both.)
One of the issues that still remains: shape-shifting recipes can't be
called with literals for addresses, even if it's 0.
|
| |
|
|
|
|
| |
In debugging 2438, I spent a while going around in circles trying to
decide if there was a stray overload of 'interactive'. Part of the
problem was the hacky delete of a recipe just above. Stop doing that.
|
| | |
|
| |
|
|
|
|
|
| |
What was I thinking with 2366?
Thanks Caleb Couch. It turned out we couldn't call shape-shifting
recipes inside the edit/ or sandbox/ apps.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Thanks Caleb Couch. This one's been on my list for 2 weeks.
|
| |
|
|
| |
More evocative, less jargony.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
If a name repeats between ingredients, we raise an error.
If a name repeats across ingredients and products, every call should
share the same name across the corresponding ingredients and products.
|
| | |
|
| |
|
|
| |
This is the last one I can think of.
|
| | |
|
| |
|
|
| |
This time for the support for 'new' that was added in 2393.
|
| |
|
|
| |
Tiny patch for such a large change, but we do what we can.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
One new issue: the traces for all tests are perturbed by the .mu files we
choose to load.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
And it caught a bug: I mean to always update type names and types in
sync.
The last month or so I've been getting reluctantly but inexorably
converted to the need and value of a type system. First I thought I just
need a minimal but rigorous type system to avoid memory corruption and
security issues. Now I think I also want it to be expressive enough to
be able to express what data different phases in a compiler read and
write, and to be able to designate specific fields as 'fully computed'
so that we can statically check that phases wait until their data is
available.
The phase-ordering problem in a compiler is perhaps the canary in the
coal-mine for a more general problem: even small changes can
dramatically explode the state space if they violate assumptions
previously held about the domain. My understanding of when type pointers
are null and not null is immeasurably more nuanced today than it was a
week ago, but I didn't need the nuance until I introduced generic
functions. That initial draft of a hundred lines bumped me up to a much
larger state space. How to make it more obvious when something happens
that is akin to discovering a new continent, or finding oneself
teleported to Jupiter?
Assumptions can be implicit or explicit. Perhaps a delete of an
assertion should be estimated at 1000 LoC of complexity?
|
| |
|
|
|
|
|
| |
Is that like a Maybe type in a type system? No it's more, it captures
the wistful longing of several hours spent trying to make an assertion
true. Not even by moving my phases relating to the types around could I
make this assertion true.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I tried to not populate the type at an early stage, and to pull out the
type computations for all reagents into a separate transform grouped
with but before the other type deduction transforms. But it seemed less
readable to not mention types at all in layer 10. So we'll stick with
our current approach, but try to be disciplined about grouping all the
type transforms together, so that we can reason about whether a pass
belongs before or after type deduction. (Doesn't seem rigorous enough
for the name 'type inference'.) In particular, static dispatch and
specialization of generics (resolve_ambiguous_calls) needs to happen
after all type inference has completed, so that the only missing types
are the generic type ingredients.
In general I've been living in constant fear of the phase-ordering
problem. No matter how many tests I write, I can't be sure that there
isn't some corner case where my phases will be proven to be in a
sub-optimal ordering. When I build the mu compiler in mu I'll want to
also use the ability to perform static analyses in mu programs using mu
userland capabilities. That would allow me to be sure that no phase
writes to some field of reagent after some other purely checking phase
reads it. Then all you have to do is be disciplined about not doing
checking in mutating phases (which we currently aren't; hello
check_or_set_invalid_types).
Hmm, but I think this line of thought gives me some confidence now that
I'm ok so far. The only field of reagents being modified after
parsing/initialization is the type. So all I care about is whether each
transform happens before or after all types are available. If I later
start writing other fields or properties then I'll need to perform
similar analysis for them, and it might get complicated enough to need a
state diagram where partially filled out properties inhabit separate
states from completely inferred properties.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
Fix that stray issue with a better phase ordering.
Another thing I'm not testing.
|