| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| | |
|
| |
|
|
|
|
|
|
|
| |
I notice that it isn't working perfectly; after maximize/unmaximize the
editor stops wrapping text, like it still thinks the editor is
maximized.
We don't even use this feature anymore, do we? Just delete it rather
than bother debugging.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
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.
|
| | |
|