| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
| |
Another CI fix.
|
| |
|
|
| |
More helpful messages when people forget 'load-ingredients'.
|
| | |
|
| |
|
|
|
|
| |
As long as Mu operates atop Unix, we need to make these assumptions.
Thanks Ella Couch for finding this loophole.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Always check if next_word() returned an empty string (if it hit eof).
Thanks Rebecca Allard for running into a crash when a .mu file ends with
'{' (without a following newline).
Open question: how to express the constraint that next_word() should
always check if its result is empty? Can *any* type system do that?!
Even the usual constraint that we must use a result isn't iron-clad: you
could save the result in a variable but then ignore it. Unless you go to
Go's extraordinary lengths of considering any dead code an error.
|
| | |
|
| |
|
|
|
|
|
|
| |
Drop an ancient case of premature optimization: skipping transform for
recipes without bodies. These days recipes also have headers that need
transforming.
Thanks Caleb Couch for running into this issue.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Can't use type abbreviations inside 'memory-should-contain'.
|
| |
|
|
|
|
|
| |
Process type abbreviations in function headers.
Still a couple of places where doing this causes strange errors. We'll
track those down next.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The old approach with '&' and '@' modifiers turned out to be a bad idea
because it introduces notions of precedence. Worse, it turns out you
want different precedence rules at different times as the old test
alluded:
x:@number:3 # we want this to mean (address number 3)
x:address:@number # we want this to mean (address array number)
Instead we'll give up and focus on a single extensible mechanism that
allows us to say this instead:
x:@:number:3
x:address:@:number
In addition it allows us to shorten other types as well:
x:&:@:num
type board = &:@:&:@:char # for tic-tac-toe
Hmm, that last example reminds me that we don't handle abbreviations
inside type abbreviation definitions so far..
|
| |
|
|
|
|
|
|
| |
Always show instruction before any transforms in error messages.
This is likely going to make some errors unclear because they *need* to
show the original instruction. But if we don't have tests for those
situations did they ever really work?
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
Standardize quotes around reagents in error messages.
I'm still sure there's issues. For example, the messages when
type-checking 'copy'. I'm not putting quotes around them because in
layer 60 I end up creating dilated reagents, and then it's a bit much to
have quotes and (two kinds of) brackets. But I'm sure I'm doing that
somewhere..
|
| |
|