| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
Got that idea to work with a special-case for 'new'. Requires parsing
new's first ingredient, performing the replacement, and then turning it
back into a string. I didn't want to replace NEW with ALLOCATE right
here, because then it messes with my invariant that transform should
never see a naked ALLOCATE.
Layer 11 still not working, but everything else is. Let's clean up
before we diagnose the new breakage.
|
| |
|
|
| |
Yup, type ingredients were taking size 1 by default.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
No, my idea was abortive. My new plan was to run no transforms for
generic recipes, and instead only run them on concrete specializations
as they're created.
The trouble with this approach is that new contains a type specification
in its ingredient which apparently needed to be transformed into an
allocate before specialization.
But no, how was that working? How was new computing size based on type
ingredients? It might have been wrong all along.
|
| |
|
|
|
| |
I'd not paid any attention to it so far, but I need to do so from now
on.
|
| |
|
|
| |
Starting to leave commented out prints again out of desperation.
|
| |
|
|
|
|
|
| |
Commands run:
$ sed -i 's/\([^. (]*\)\.find(\([^)]*\)) != [^.]*\.end()/contains_key(\1, \2)/g' 0[^0]*cc
$ sed -i 's/\([^. (]*\)\.find(\([^)]*\)) == [^.]*\.end()/!contains_key(\1, \2)/g' 0[^0]*cc
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I'm still seeing all sorts of failures in turning on layer 11 of edit/,
so I'm backing away and nailing down every culprit I run into. First up:
stop accidentally inserting empty objects into maps during lookups.
Commands run:
$ sed -i 's/\(Recipe_ordinal\|Recipe\|Type_ordinal\|Type\|Memory\)\[\([^]]*\)\] = \(.*\);/put(\1, \2, \3);/' 0[1-9]*
$ vi 075scenario_console.cc # manually fix up Memory[Memory[CONSOLE]]
$ sed -i 's/\(Memory\)\[\([^]]*\)\]/get_or_insert(\1, \2)/' 0[1-9]*
$ sed -i 's/\(Recipe_ordinal\|Type_ordinal\)\[\([^]]*\)\]/get(\1, \2)/' 0[1-9]*
$ sed -i 's/\(Recipe\|Type\)\[\([^]]*\)\]/get(\1, \2)/' 0[1-9]*
Now mu dies pretty quickly because of all the places I try to lookup a
missing value.
|
| |
|
|
|
|
|
|
|
| |
More flailing around trying to come up with the right phase ordering.
I've tried to narrow down each transform's constraints wrt transforms in
previous layers.
One issue that keeps biting me is the Type map containing empty records
because of stray [] operations. That's gotta be important.
|
| |
|
|
|
|
|
| |
A new externality is starting to make its presence felt.
Until I sort this out it's going to be hard to finish making duplex-list
generic.
|
| |
|
|
|
| |
I keep finding null property pointers and am fucking sick of wondering
if it's because of this horseshit.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
At the lowest level I'm reluctantly starting to see the need for errors
that stop the program in its tracks. Only way to avoid memory corruption
and security issues. But beyond that core I still want to be as lenient
as possible at higher levels of abstraction.
|
| | |
|
| |
|
|
|
|
|
|
| |
Always show recipe name where error occurred. But don't show internal
'interactive' name for sandboxes, that's just confusing.
What started out as warnings are now ossifying into errors that halt all
execution. Is this how things went with C and Unix as well?
|
| |
|
|
|
|
|
|
|
| |
Front-loads it a bit more than I'd like, but the payoff is that other
recipes will now be able to describe the type checks right next to their
operation.
I'm also introducing a new use of /raw with literals to indicate unsafe
typecasts.
|
| |
|