| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| |
|
|
|
| |
One more place we were missing expanding type abbreviations: inside
container definitions.
|
| |
|
|
| |
Can't use type abbreviations inside 'memory-should-contain'.
|
| |
|
|
| |
Fix a couple of failing example programs.
|
| |
|
|
|
|
|
|
|
|
|
| |
Turns out we don't need a primitive to return an empty value of
arbitrary type. Just create it on the heap using 'new'.
But this uncovered *yet* another bug, sigh. When I specialize generic
functions I was running all transforms on the generated functions after
specialization completed. But there's one transform that includes code
from elsewhere. If such code included type-ingredients -- kaboom. Now
fixed and there's a test, so I've got that going for me which is nice.
|
| |
|
|
|
|
|
| |
Now that we no longer have non-shared addresses, we can just always
track refcounts for all addresses.
Phew!
|
| |
|
|
|
|
| |
I've ignored Mu's concurrency primitives for a while, but they're
starting to return to front-and-center as I work on the file system
interfaces.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
I'm dropping all mention of 'recipe' terminology from the Readme. That
way I hope to avoid further bike-shedding discussions while I very
slowly decide on the right terminology with my students.
I could be smarter in my error messages and use 'recipe' when code uses
it and 'function' otherwise. But what about other words like ingredient?
It would all add complexity that I'm not yet sure is worthwhile. But I
do want separate experiences for veteran programmers reading about Mu on
github and for people learning programming using Mu.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
We want to use the type 'recipe' for recipe *variables*, because it
seems nicer to say `recipe number -> number` rather than recipe-ordinal,
etc. To support this we'll allow recipe names to be mentioned without
any type.
This might make a couple of places in this commit more brittle. I'm
dropping error messages, causing them to not happen in some situations.
Maybe I should just bite the bullet and require an explicit
:recipe-literal. We'll see.
|
| | |
|
| |
|
|
|
|
|
|
| |
We still can't check ingredient types, and even this is still a run-time
check. We'll need to start tracking recipe signatures at some point.
I've had to introduce a hack called /skiptypecheck. Time to get generics
working.
|
| | |
|
| |
|
|
| |
First step to reducing typing burden. Next step: inferring types.
|
| |
|
|
|
|
| |
But still no difference in either memory footprint or in running time.
This will teach me -- for the umpteenth time -- to optimize before
measuring.
|
| |
|
|
|
| |
Turns out to not affect memory utilization or run-time. At all.
But still looks nicer and requires less fudging on our part.
|
| | |
|
| |
|
|
| |
..now that we support non-integers.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
All primitives now always write to all their products. If a product is
not used that's fine, but if an instruction seems to expect too many
products mu will complain.
In the process, many primitives can operate on more than two ingredients
where it seems intuitive. You can add or divide more than two numbers
together, copy or negate multiple corresponding locations, etc.
There's one remaining bit of ugliness. Some instructions like
get/get-address, index/index-address, wait-for-location, these can
unnecessarily load values from memory when they don't need to.
Useful vim commands:
%s/ingredients\[\([^\]]*\)\]/ingredients.at(\1)/gc
%s/products\[\([^\]]*\)\]/products.at(\1)/gc
.,$s/\[\(.\)]/.at(\1)/gc
|
| |
|
|
| |
I've tried to update the Readme, but there are at least a couple of issues.
|
| |
|
|
|
|
| |
Swap printing generalized objects using arc's infrastructure to be the
$-prefixed debug helper, while the erstwhile $print-key-to-host becomes
the primitive print-character to host.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
I dunno, this may all be a wild goose chase. I haven't been disciplined
in tagging in-out arguments in 'read-move' and its helpers. Maybe I
should just drop those 'nochange' oargs in 'read' and 'write'. Maybe I
should reserve output args only for return values that callers might
actually care about, and use more conventional metadata like 'const' or
'unique' or 'inout' on other args.
|
| |
|
|
|
| |
Also clean up various prints from last few commits.
As a convention, for debugging we always print directly to host.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This will let me swap in a fake in tests.
Still hacky, though. I'm sure I'm not managing the parameter right in
the chessboard app.
And then there's the question of whether it should also appear as an
output operand.
But it's a start. And using nil to mean 'real' is a reasonable
convention.
If I ever need to handle multiple screens perhaps we'll have to switch
to 1:literal/terminal and 2:literal/terminal, etc. But those are equally
easy to guard on.
|
| | |
|
| | |
|
| |
|
|
| |
Fork syntax is now: fork <function> [global space] [max cycle limit] args*
|
| |
|
|
| |
For new interface to 'sleep' at 511.
|
| | |
|
| |
|
|
|
|
|
| |
I could swear there was an issue earlier where tagged-values had to
contain pointers for some core function. But I can't find it anymore.
Ok, assume we can store primitives in it and pointers only for
aggregates (and-records and arrays).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
'default-scope' is now 'default-space'
'closure-generator' is now 'next-space-generator'
The connection to high-level syntax for closures is now tenuous, so
we'll call the 'outer scope' the 'next space'.
So, let's try to create a few sentences with all these related ideas:
Names map to addresses offset from a default-space when it's provided.
Spaces can be strung together. The zeroth variable points to the next
space, the one that is accessed when a variable has /space:1.
To map a name to an address in the next space, you need to know what
function generated that space. A corollary is that the space passed in
to a function should always be generated by a single function.
Spaces can be used to construct lexical scopes and objects.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
We expect users to come across mu from arbitrary bits of code, so try to
make each line as self-contained as possible.
|
| |
|
|
| |
Thanks Kristis Makris for the bug report.
|
| |
|